Impact pg_repack on streaming replication

[nik-weter]

Hello.
I have one db with streaming replication. Both instances had size about 252Gb
Then pg_repack was running.
After pg_repack primary postgres cluster had size about 230Gb.
But replica had size about 308Gb!
Now primary is 232Gb, secondary - 310Gb.
Could you please to explain this situation ang give me path to avoid it.

[MichaelDBA]

Perhaps your replica has not caught up with the primary yet.

[nik-weter]

2 weeks since then
master 255Gb - replica 329Gb
backup from replica restore correctly.

[MichaelDBA]

@nik-weter please do some work, instead of just reporting the db size diff, please compare tables sizes to isolate which table or tables are different.

Here, let me help you out:

RUN this to isolate schema size diffs:

SELECT schemaname, pg_size_pretty(sum(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename)))::bigint) schemasize FROM pg_tables t 
WHERE schemaname not in ('pg_catalog','information_schema') AND schemaname not like 'pg_temp%' group by 1 order by sum(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename)))::bigint desc;

Then run this one for the schemas that have diff sizes compared to primary for individual tables:

SELECT schemaname as schema, tablename, pg_size_pretty(sum(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename)))::bigint),  sum(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename))) 
FROM pg_tables WHERE schema = 'YOUR SCHEMA' group by 1,2 order by 4 desc,1,2;

[MichaelDBA]

Closing this issue due to lack of response from issue creator.