Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
От | Drouvot, Bertrand |
---|---|
Тема | Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed |
Дата | |
Msg-id | d40d015f-03a4-1cf2-6c1f-2b9aca860762@gmail.com обсуждение исходный текст |
Ответ на | Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
|
Список | pgsql-hackers |
Hi, On 5/30/23 12:34 PM, Drouvot, Bertrand wrote: > Hi hackers, > > Please find attached a patch proposal to $SUBJECT. > > Indeed, we have seen occurrences in [1] that some slots were > not invalidated (while we expected vacuum to remove dead rows > leading to slots invalidation on the standby). > > Though we don't have strong evidences that this > was due to transactions holding back global xmin (as vacuum did > not run in verbose mode), suspicion is high enough (as Tom pointed > out that the test is broken on its face (see [1])). > > The proposed patch: > > - set autovacuum = off on the primary (as autovacuum is the usual suspect > for holding global xmin). > - Ensure that vacuum is able to remove dead rows before launching > the slots invalidation tests. > - If after 10 attempts the vacuum is still not able to remove the dead > rows then the slots invalidation tests are skipped: that should be pretty > rare, as currently the majority of the tests are green (with only one attempt). > > While at it, the patch also addresses the nitpicks mentioned by Robert in [2]. > > [1]: https://www.postgresql.org/message-id/flat/OSZPR01MB6310CFFD7D0DCD60A05DB1C3FD4A9%40OSZPR01MB6310.jpnprd01.prod.outlook.com#71898e088d2a57564a1bd9c41f3e6f36 > [2]: https://www.postgresql.org/message-id/CA%2BTgmobHGpU2ZkChgKifGDLaf_%2BmFA7njEpeTjfyNf_msCZYew%40mail.gmail.com > Please find attached V2 that, instead of the above proposal, waits for a new snapshot that has a newer horizon before doing the vacuum (as proposed by Andres in [1]). So, V2: - set autovacuum = off on the primary (as autovacuum is the usual suspect for holding global xmin). - waits for a new snapshot that has a newer horizon before doing the vacuum(s). - addresses the nitpicks mentioned by Robert in [2]. V2 also keeps the verbose mode for the vacuum(s) (as done in V1), as it may help for further analysis if needed. [1]: https://www.postgresql.org/message-id/20230530152426.ensapay7pozh7ozn%40alap3.anarazel.de [2]: https://www.postgresql.org/message-id/CA%2BTgmobHGpU2ZkChgKifGDLaf_%2BmFA7njEpeTjfyNf_msCZYew%40mail.gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: