On 23 January 2017 at 12:34, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 20 January 2017 at 21:40, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > >> One option would be to add another limit Xid which advances before the >> truncation but which is not used for other decisions other than limiting >> what can users consult. > > This could be useful for other things, but it's probably heavier than needed. > > What I've done in the latest revision of the txid_status() patch is > simply to advance OldestXid _before_ truncating the clog. The rest of > the xid info is advanced after. Currently this is incorporated into > the txid_status patch, but can be separated if desired. > > Relevant commit message portion: > > There was previously no way to look up an arbitrary xid without > running the risk of having clog truncated out from under you. This > hasn't been a problem because anything looking up xids in clog knows > they're protected by datminxid, but that's not the case for arbitrary > user-supplied XIDs. clog was truncated before we advance oldestXid so > taking XidGenLock was insufficient. There's no way to look up a > SLRU with soft-failure. To address this, increase oldestXid under > XidGenLock > before we trunate clog rather than after, so concurrent access is safe. > > Note that while oldestXid is advanced before clog truncation, the xid > limits are advanced _after_ it. If we advanced the xid limits before > truncation too, we'd theoretically run the risk of allocating an xid > from the clog section we're about to truncate, which would be no fun. > (In practice it can't really happen since we only use 1/2 the > available space at a time). > > Moving the lower bound up, truncating, and moving the upper bound up > is the way to go IMO.
Patch with explanation in commit msg: https://www.postgresql.org/message-id/camsr+yhodeduua5vw1_rjps_assvemejn_34rqd3pzhf5of...@mail.gmail.com -- 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
