Hi,
Due to [1] I thought it'd be a good idea to write an isolation test for
testing postgres_fdw interruptability during connection establishment.
I was able to make that work - but unfortunately doing so requires preventing
a login from completing. The only way I could see to achieve that is to lock
one of the important tables. I ended up with
step s2_hang_logins { LOCK pg_db_role_setting; }
However, I'm a bit worried that that might cause problems. It'll certainly
block progress in concurrent tests, given it's a shared relation. But locking
relevant non-shared relations causes more problems, because it'll e.g. prevent
querying pg_stat_activity.
Does anybody see another way to cause a login to hang as part of an isolation
test, in a controllable manner? Or, if not, do you think we can get away with
locking pg_db_role_setting?
The other complexity is that isolationtester won't see the wait edge going
through postgres_fdw. My approach for that is to do that one wait in a DO
block loop, matching on application_name = 'isolation/interrupt/s1'.
I don't think we can teach isolationtester to understand such edges. I guess
we could teach it to wait for certain wait events though? But I'm not sure how
generally useful that is. IIRC Tom concluded in the past that it didn't get us
very far.
The test currently tests one termination case, because isolationtester will
just fail the next permutation if a connection is gone. I don't see an issue
fixing that?
I attached my current WIP patch for the test.
Note that the test will only work with the patches from [1] applied.
Greetings,
Andres Freund
[1] https://www.postgresql.org/message-id/20220925232237.p6uskba2dw6fnwj2%40awork3.anarazel.de