On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier
> 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
It won't affect anything unless running at transaction isolation level
serializable with the "read only deferrable" option.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: