Re: Some pgq table rewrite incompatibility with logical decoding?

>
>
Interesting.
>
> So you were running 9.6.9 before, it triggered the issue (and was not
> able to recover). You took a filesystem snapshot, started a 9.6.10 on
> the snapshot, and it recovered without hitting the issue?
>

I am resposting this to the list and not only to Tomas. Tomas, I can’t
promise just yet to delve into this because given the patch fixes the issue
it’s obviously much lower priority for our team. Are you hoping for me to
confirm the exact scenario in which the 9.6.10 patch fixes the bug?

Actually, there were more things changed than that so I'm not positive it
was the last patch:

BEFORE:
Provider - 9.6.8-1.pgdg16.04+1, pglogical 2.1.1-1.xenial+1
Subscriber - 9.6.9-2.pgdg16.04+1, 2.1.1-1.xenial+1

AFTER:
Provider - 9.6.10-1.pgdg16.04+1, pglogical 2.2.0-3.xenial+1
Subscriber - 9.6.10-1.pgdg16.04+1, pglogical 2.2.0-3.xenial+1

> I quickly went through the commits in 9.6 branch between 9.6.9 and
> 9.6.10, looking for stuff that might be related, and these three commits
> seem possibly related (usually because of invalidations, vacuum, ...):
>
> 6a46aba1cd6dd7c5af5d52111a8157808cbc5e10
> Fix bugs in vacuum of shared rels, by keeping their relcache entries
> current.
>
> da10d6a8a94eec016fa072d007bced9159a28d39
> Fix "base" snapshot handling in logical decoding
>
> 0a60a291c9a5b8ecdf44cbbfecc4504e3c21ef49
> Add table relcache invalidation to index builds.
>
> But it's hard to say if/which of those commits did the trick, without
> more information.
>

Let me know if that info gives you any more insight - actually 2 point
version jumps for provider, 1 for subscriber.

Thanks,
Jeremy