On Thu, Jan 5, 2017 at 6:41 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > 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...
Do you think that expanding the wait query by default could be intrusive for the other tests? I am wondering about such a white list to generate false positives for the existing tests, including out-of-core extensions, as all the tests now rely only on pg_blocking_pids(). -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
