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
