On 7 June 2012 17:34, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 7 June 2012 14:56, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Say what? That's a performance result and proves not a damn thing about >>> safety. > >> Of course not. > >> Based on the rationale explained in the code comments in the patch, it >> seems like a reasonable thing to me now. > >> The argument was that since we hold AccessExclusiveLock on the >> relation, no other agent can be reading in new parts of the table into >> new buffers, so the only change to a buffer would be away from the >> dropping relation, in which case we wouldn't care. Which seems correct >> to me. > > Oh, I must be confused about which patch we are talking about --- I > thought this was in reference to some of the WIP ideas that were being > thrown about with respect to using lock-free access primitives. Which > patch are you proposing for commit now, exactly?
Both of these, as attached up thread. Simon's patch - dropallforks.v1.patch Jeff's patch - DropRelFileNodeBuffers_unlock_v1.patch (needs a little tidyup) -- Simon Riggs 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
