On 2017-05-29 23:49:33 +0200, Petr Jelinek wrote: > I am not quite sure I understand (both the vxid suggestion and for the > session dying badly). Maybe we can discuss bit more when you get to > computer so it's easier for you to expand on what you mean.
The xid interlock when exporting a snapshot is required because otherwise it's not generally guaranteed that all resourced required for the snapshot are reserved. In the logical replication case we could guarantee that otherwise, but there'd be weird-ish edge cases when erroring out just after exporting a snapshot. The problem with using the xid as that interlock is that it requires acquiring an xid - which is something we're going to block against when building a new catalog snapshot. Afaict that's not entirely required - all that we need to verify is that the snapshot in the source transaction is still running. The easiest way for the importer to check that the source is still alive seems to be export the virtual transaction id instead of the xid. Normally we can't store things like virtual xids on disk, but that concern isn't valid here because exported snapshots are ephemeral, there's also already a precedent in predicate.c. It seems like it'd be fairly easy to change things around that way, but maybe I'm missing something. - Andres -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers