On 08/06/2013 02:37 AM, Robert Haas wrote:
> I haven't read this particular test, but I do think we could get a lot
> of mileage out of applying the isolation tester stuff to more things,
> and am generally in favor of that. It has the advantages of (1)
> allowing tests that require more than one session and (2) being run
> regularly the buildfarm; but it's not something developers typically
> run before every commit, so the run time of the test suite shouldn't
> be a big issue for anyone.
The main issue with the test is that it's a dirty hack. What I really
want is a way to block a statement at a certain point - to say "block
after a snapshot is acquired" for example - and release that at a time
of my choosing.
That would require hooks (either callable from SQL in debug builds or
only accessible via C extensions) that can block until released by
action from another backend or after a timeout. The hook call sites
would be macros that're defined away unless the hooks were enabled at
compile time, in which case a shared_preload_library could register a
callback on a hook to do whatever it needs to do. The library would
probably expose some SQL functions as an extension to allow SQL-level
manipulation of the blocking/timeout behaviour.
Such hooks would be really useful for testing complex concurrency cases
that can't be expressed at the statement level. I usually just use a
"LOCK TABLE blah IN ACCESS EXCLUSIVE MODE" to set up a race, but that's
only useful when your issue is at the statement level. It's also not
possible to do this with isolationchecker, because it seems it can only
cope with one blocked session at a time and you need (at least) three
for this approach.
Opinions? Is this something that's even worth thinking about further or
a non-starter?
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
