On Thu, Jan 5, 2017 at 7:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro
>>> <thomas.munro@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