On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Jan 5, 2017 at 6:41 AM, Thomas Munro
> <thomas.munro@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