On Thu, Jan 5, 2017 at 7:41 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro >>> <thomas.mu...@enterprisedb.com> wrote: >>>> To be able to do this, the patch modifies the isolation tester so that >>>> it recognises wait_event SafeSnapshot. >>> >>> I'm not going to say that's unacceptable, but it's certainly not beautiful. >> >> Perhaps being able to define in an isolation spec a step called >> 'wait_event' with a value defined to the wait event to look for would >> make more sense? > > That'd be a much bigger change, since currently waiting is entirely implicit.
It's a bit of a strange case: we're indirectly waiting for other backends' transactions to end, but it's not exactly a lock or even a predicate lock: it's waiting for a time when we could run safely with predicate locking disabled. So it's not at all clear that pg_blocking_pids should try to get its hands on the appropriate pids (or if it even could). Hence my attempt to do this using our wonderful wait introspection. I don't think putting the particular wait_event name into the test spec would be very useful. It's really there as a whitelist to be conservative about excluding random waits caused by concurrent autovacuum etc. It just happens to have only one thing in the whitelist for now, and I'm not sure what else would ever go in it... -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers