On 8 October 2017 at 02:37, Daniele Varrazzo <daniele.varra...@gmail.com> wrote: > Hello, > > we have been reported, and I have experienced a couple of times, > pg_repack breaking logical replication. > > - https://github.com/reorg/pg_repack/issues/135 > - https://github.com/2ndQuadrant/pglogical/issues/113
Yeah, I was going to say I've seen reports of this with pglogical, but I see you've linked to them. I haven't had a chance to look into it though, and haven't had a suitable reproducible test case. > In the above issue #113, Petr Jelinek commented: > >> From quick look at pg_repack, the way it does table rewrite is almost >> guaranteed >> to break logical decoding unless there is zero unconsumed changes for a >> given table >> as it does not build the necessary mappings info for logical decoding that >> standard >> heap rewrite in postgres does. > > unfortunately he didn't follow up to further details requests. At a guess he's referring to src/backend/access/heap/rewriteheap.c . I'd explain better if I understood what was going on myself, but I haven't really understood the logical decoding parts of that code. > - Is Petr diagnosis right and freezing of logical replication is to be > blamed to missing mapping? > - Can you suggest a test to reproduce the issue reliably? > - What are mapped relations anyway? I can't immediately give you the answers you seek, but start by studying src/backend/access/heap/rewriteheap.c . Notably logical_end_heap_rewrite, logical_rewrite_heap_tuple, logical_begin_heap_rewrite. At a wild "I haven't read any of the relevant code in detail yet" stab in the dark, pg_repack is failing to do the bookkeeping required by logical decoding around relfilenode changes, cmin/cmax, etc. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers