On 31/05/17 09:24, Andres Freund wrote: > 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. >
Okay, thanks for explanation. Code-wise it does seem simple enough indeed. I admit I don't know enough about the exported snapshots and snapshot management in general to be able to answer the question of safety here. That said, it does seem to me like it should work as the exported snapshots are just on disk representation of in-memory state that becomes invalid once the in-memory state does. -- Petr Jelinek 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
