Re: Question about InvalidatePossiblyObsoleteSlot()
| От | Bertrand Drouvot |
|---|---|
| Тема | Re: Question about InvalidatePossiblyObsoleteSlot() |
| Дата | |
| Msg-id | aQLnEne32N8m/i7O@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
| Ответ на | Re: Question about InvalidatePossiblyObsoleteSlot() (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Question about InvalidatePossiblyObsoleteSlot()
|
| Список | pgsql-hackers |
Hi, On Thu, Oct 30, 2025 at 11:25:18AM +0900, Michael Paquier wrote: > On Wed, Oct 29, 2025 at 08:55:56AM +0000, Bertrand Drouvot wrote: > > > That's the test instability that triggered 818fefd8fd4 and not any report > > from the field. I think that pre-818fefd8fd4 behavior has been there for a > > while and that hitting the inconsistency is a pathological case. I'd vote for > > do nothing unless we get complaints from the field. > > I am not sure that there is anything else to be done, but let's just > revert the change in v16~ for now. As far as I can see, the change is > straight-forward in v16, slightly funky in v17 as "invalidation_cause" > is a rename of "conflict", while your patch captures the refactoring > of v18~ under DetermineSlotInvalidationCause(). I have run a few > hundred loops of 035_standby_logical_decoding for v16 and v17, in > case, without seeing problems. Now the original race was also hard to > see. The tests are also stabilized on 17 thanks to 17a165d60f73 and on 16 thanks to 86392e8827d8, so I think that we should be fine on those branches too. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: