> I thought about having special field (or reusing one of the existing fields) > in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin > as Petr suggested. Then this logic can reside in ReorderBufferCommit(). > However this is not solving problem with catcache, so I'm looking into it > right now.
OK, so this is only an issue if we have xacts that change the schema of tables and also insert/update/delete to their heaps. Right? So, given that this is CF3 for Pg10, should we take a step back and impose the limitation that we can decode 2PC with schema changes or data row changes, but not both? Applications can record DDL in transactional logical WAL messages for decoding during 2pc processing. Or apps can do 2pc for DML. They just can't do both at the same time, in the same xact. Imperfect, but a lot less invasive. And we can even permit apps to use the locking-based approach I outlined earlier instead: All we have to do IMO is add an output plugin callback to filter whether we want to decode a given 2pc xact at PREPARE TRANSACTION time or defer until COMMIT PREPARED. It could: * mark the xact for deferred decoding at commit time (the default if the callback doesn't exist); or * Acquire a lock on the 2pc xact and request immediate decoding only if it gets the lock so concurrent ROLLBACK PREPARED is blocked; or * inspect the reorder buffer contents for row changes and decide whether to decode now or later based on that. It has a few downsides - for example, temp tables will be considered "catalog changes" for now. But .. eh. We already accept a bunch of practical limitations for catalog changes and DDL in logical decoding, most notably regarding practical handling of full table rewrites. > Just as before I marking this transaction committed in snapbuilder, but after > decoding I delete this transaction from xip (which holds committed > transactions > in case of historic snapshot). That seems kind of hacky TBH. I didn't much like marking it as committed then un-committing it. I think it's mostly an interface issue though. I'd rather say SnapBuildPushPrepareTransaction and SnapBuildPopPreparedTransaction or something, to make it clear what we're doing. -- 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
