On Sat, Apr 8, 2017 at 9:47 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner <kgri...@gmail.com> wrote: >>> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund <and...@anarazel.de> wrote: >>> >>>> I'd rather fix the issue, than remove the tests entirely. Seems quite >>>> possible to handle blocking on Safesnapshot in a similar manner as >>>> pg_blocking_pids? >>> >>> I'll see what I can figure out. >> >> Ouch. These are the other ways I thought of to achieve this: >> >> https://www.postgresql.org/message-id/CAEepm%3D1MR4Ug9YsLtOS4Q9KAU9aku0pZS4RhBN%3D0LY3pJ49Ksg%40mail.gmail.com >> >> I'd be happy to write one of those, but it may take a day as I have >> some other commitments. > > Please give it a go. I'm dealing with putting out fires with > customers while trying to make sure I have tested the predicate > locking GUCs patch sufficiently. (I think it's ready to go, and has > passed all tests so far, but there are a few more I want to run.) > I'm not sure I can come up with a solution faster than you, given > that. Since it is an improvement to performance for a test-only > environment on a feature that is already committed and not causing > problems for production environments, hopefully people will tolerate > a fix a day or two out. If not, we'll have to revert and get it > into the first CF for v11.
Here is an attempt at option 2 from the menu I posted above. Questions: 1. Does anyone object to this extension of pg_blocking_pids()'s remit? If so, I could make it a separate function (that was option 3). 2. Did I understand correctly that it is safe to scan the list of SERIALIZABLEXACTs and access the possibleUnsafeConflicts list while holding only SerializableXactHashLock, and that 'inLink' is the correct link to be following? -- Thomas Munro http://www.enterprisedb.com
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers