On Mon, Sep 19, 2016 at 9:54 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> You appear to have attached the wrong patch set. > > Whoops, multitasking fail. > > Sorry for the late response, hospitals are "fun".
I did some cleanup of 0001 (see attached) and was all set to commit it when I realized what I think is a problem: holding XidGenLock doesn't seem to help with the race condition between this function and CLOG truncation, because vac_truncate_clog() updates the shared memory limits AFTER performing the truncation. If the order of those operations were reversed, we'd be fine, because it would get stuck trying to update the shared memory limits and wouldn't be able to truncate until it did - and conversely, if it updated the shared memory limits before we examined them, that would be OK, too, because we'd be sure not to consult the pages that are about to be truncated. As it is, though, I don't see that there's any real interlock here. (BTW, the stuff you moved from clog.c to clog.h doesn't actually need to be moved; one of the changes I made here was to undo that.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
txid-status-rmh.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
