On Tue, Dec 19, 2017 at 1:31 PM, Andres Freund <andres@anarazel.de> wrote:
> Could I perhaps convince somebody to add that as a feature to
> isolationtester? I'm willing to work on a bugfix for the bug itself, but
> I've already spent tremendous amounts of time, energy and pain on
> multixact bugs, and I'm at the moment feeling a bit unenthusiastic about
> also working on test infrastructure for it... If somebody else is
> willing to work on both infrastructure *and* a bugfix, that's obviously
> even better ;)
Hmm. The problem with trying to make the isolation tester do this is
that pg_isolation_test_session_is_blocked(X, A) is documented to tell
us whether X is waiting for one the PIDs listed in A. It's easy
enough to tell whether X is blocked waiting for a cleanup lock by
looking at BackendPidGetProc(pid)->wait_event_info, but that gives us
no information about which processes are holding the buffer pins that
prevent us from acquiring that lock. That's a hard problem to solve
because that data is not recorded in shared memory and doing so would
probably be prohibitively expensive.
<me thinks for a while>
What if we add a hook to vacuum that lets you invoke some arbitrary C
code after each block, and then write a test module that uses that
hook to acquire and release an advisory lock at that point? Then you
could do:
S1: SELECT pg_advisory_lock(...);
S2: VACUUM; -- blocks on S1, because of the test module
S3: UPDATE ...;
S1: COMMIT; -- unblocks VACUUM
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
