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 | Za4wYVsAliqH4XYH@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 Mon, Jan 22, 2024 at 03:54:44PM +0900, Michael Paquier wrote: > On Fri, Jan 19, 2024 at 09:03:01AM +0000, Bertrand Drouvot wrote: > > On Fri, Jan 19, 2024 at 09:00:01AM +0300, Alexander Lakhin wrote: > +# Launch $sql and wait for a new snapshot that has a newer horizon before > +# doing the vacuum with $vac_option on $to_vac. > +sub wait_until_vacuum_can_remove > > This had better document what the arguments of this routine are, > because that's really unclear. $to_vac is the relation that will be > vacuumed, for one. Agree, done that way in v8 attached. > Also, wouldn't it be better to document in the test why > txid_current_snapshot() is chosen? Contrary to txid_current(), it > does not generate a Transaction/COMMIT to make the test more > predictible, something you have mentioned upthread, and implied in the > test. Good point, added more comments in v8 (but not mentioning txid_current() as after giving more thought about it then I think it was not the right approach in any case). > > - INSERT INTO flush_wal DEFAULT VALUES; -- see create table flush_wal > > This removes two INSERTs on flush_wal and refactors the code to do the > INSERT in wait_until_vacuum_can_remove(), using a SQL comment to > document a reference about the reason why an INSERT is used. Couldn't > you just use a normal comment here? Agree, done in v8. > >> I've re-tested the v6 patch today and confirmed that it makes the test > >> more stable. I ran (with bgwriter_delay = 10000 in temp.config) 20 tests in > >> parallel and got failures ('inactiveslot slot invalidation is logged with > >> vacuum on pg_authid') on iterations 2, 6, 6 with no patch applied. > >> (With unlimited CPU, when average test duration is around 70 seconds.) > >> > >> But with v6 applied, 60 iterations succeeded. > > > > Nice! Thanks for the testing! > > I need to review what you have more thoroughly, but is it OK to assume > that both of you are happy with the latest version of the patch in > terms of stability gained? That's still not the full picture, still a > good step towards that. 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. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: