On Sun, Apr 9, 2017 at 11:49 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Sun, Apr 9, 2017 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Kevin Grittner <kgrittn@gmail.com> writes:
>>> On Sat, Apr 8, 2017 at 12:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> I'm imagining an API like
>>>> isolation_test_is_waiting_for(int, int[]) returns bool
>>
>>> Good suggestion.
>>
>>> Thomas, would you like to produce a patch along these lines, or
>>> should I?
>>
>> I'll be happy to review/push if someone else does a first draft.
>
> Ok, I'll post a new patch tomorrow.
Here's a pair of draft patches for review:
1. pg-isolation-test-session-is-blocked.patch, to fix the
CACHE_CLOBBERED_ALWAYS problem by doing all the work in C as
suggested.
2. pg-safe-snapshot-blocking-pids.patch, to provide an end-user
function wrapping GetSafeSnapshotBlockingPids(). Kevin expressed an
interest in that functionality, and it does seem useful: for example,
someone might use it to investigate which backends are holding up
pg_dump --serializable-deferrrable. This is a separate patch because
you might consider it material for the next cycle, though at least
it's handy for verifying that GetSafeSnapshotBlockingPids() is working
correctly. To test, open some number of SERIALIZABLE transactions and
take a snapshot in each, and then open a SERIALIZABLE READ ONLY
DEFERRABLE transaction and try to take a snapshot; it will block and
pg_safe_snapshot_blocking_pids() will identify the culprit(s).
Thanks to Andrew Gierth for an off-list discussion about the pitfalls
of trying to use "arrayoverlap" from inside
pg_isolation_test_session_is_blocked, which helped me decide that I
should open-code that logic instead. Does that make sense?
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
