On Tue, Dec 19, 2017 at 1:31 PM, Andres Freund <and...@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
crappy-buffer-pin-wait.patch
Description: Binary data
