isolation test for postgres_fdw interruptability
От | Andres Freund |
---|---|
Тема | isolation test for postgres_fdw interruptability |
Дата | |
Msg-id | 20230121213849.vehpohqyydquk2z5@awork3.anarazel.de обсуждение исходный текст |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: