On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > 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().
It won't affect anything unless running at transaction isolation level serializable with the "read only deferrable" option. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
