Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
От | Bertrand Drouvot |
---|---|
Тема | Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed |
Дата | |
Msg-id | Za9zyHVkxHgP3hG2@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
|
Список | pgsql-hackers |
Hi, On Tue, Jan 23, 2024 at 02:50:06PM +0900, Michael Paquier wrote: > On Mon, Jan 22, 2024 at 09:07:45AM +0000, Bertrand Drouvot wrote: > > I've rewritten some of that, and applied the patch down to v16. Thanks! > > Yeah, I can clearly see how this patch helps from a theoritical perspective but > > rely on Alexander's testing to see how it actually stabilizes the test. > > Anyway, that's not the end of it. What should we do for snapshot > snapshot records coming from the bgwriter? I've mixed feeling about it. On one hand we'll decrease even more the risk of seeing a xl_running_xacts in the middle of a test, but on the other hand I agree with Tom's concern [1]: I think that we could miss "corner cases/bug" detection (like the one reported in [2]). What about? 1) Apply "wait_until_vacuum_can_remove() + autovacuum disabled" where it makes sense and for tests that suffers from random xl_running_xacts. I can look at 031_recovery_conflict.pl, do you have others in mind? 2) fix [2] 3) depending on how stabilized this test (and others that suffer from "random" xl_running_xacts) is, then think about the bgwriter. [1]: https://www.postgresql.org/message-id/1375923.1705291719%40sss.pgh.pa.us [2]: https://www.postgresql.org/message-id/flat/ZaTjW2Xh+TQUCOH0@ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: