On 27 March 2017 at 09:31, Craig Ringer <cr...@2ndquadrant.com> wrote:
> We're in the last week of the CF. If you have a patch that's nearly > ready or getting there, now would be a good time to post it for help > and input from others. > > I would really like to get this in, but we're running out of time. > > Even if you just post your snapshot management work, with the cosmetic > changes discussed above, that would be a valuable start. I'm going to pick up the last patch and: * Ensure we only add the GID to xact records for 2pc commits and aborts * Add separate callbacks for prepare, abort prepared, and commit prepared (of xacts already processed during prepare), so we aren't overloading the "commit" callback and don't have to create fake empty transactions to pass to the commit callback; * Add another callback to determine whether an xact should be processed at PREPARE TRANSACTION or COMMIT PREPARED time. * Rename the snapshot builder faux-commit stuff in the current patch so it's clearer what's going on. * Write tests covering DDL, abort-during-decode, etc Some special care is needed for the callback that decides whether to process a given xact as 2PC or not. It's called before PREPARE TRANSACTION to decide whether to decode any given xact at prepare time or wait until it commits. It's called again at COMMIT PREPARED time if we crashed after we processed PREPARE TRANSACTION and advanced our confirmed_flush_lsn such that we won't re-process the PREPARE TRANSACTION again. Our restart_lsn might've advanced past it so we never even decode it, so we can't rely on seeing it at all. It has access to the xid, gid and invalidations, all of which we have at both prepare and commit time, to make its decision from. It must have the same result at prepare and commit time for any given xact. We can probably use a cache in the reorder buffer to avoid the 2nd call on commit prepared if we haven't crashed/reconnected between the two. This proposal does not provide a way to safely decode a 2pc xact that made catalog changes which may be aborted while being decoded. The plugin must lock such an xact so that it can't be aborted while being processed, or defer decoding until commit prepared. It can use the invalidations for the commit to decide. -- 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
