Re: Fix 035_standby_logical_decoding.pl race conditions
От | Amit Kapila |
---|---|
Тема | Re: Fix 035_standby_logical_decoding.pl race conditions |
Дата | |
Msg-id | CAA4eK1+Eg-KwLX-UDY-1d0pFj45LiSaGrdrrDYv56YW+fStPLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix 035_standby_logical_decoding.pl race conditions (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Fix 035_standby_logical_decoding.pl race conditions
|
Список | pgsql-hackers |
On Wed, Apr 9, 2025 at 11:24 AM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > On Wed, Apr 09, 2025 at 12:03:06PM +0900, Michael Paquier wrote: > > On Tue, Apr 08, 2025 at 06:42:53AM +0000, Bertrand Drouvot wrote: > > > Fully agree. Will need to find another way to prevent a process to wait between the > > > wakeup and the detach. I'll open a dedicated thread. > > > > By the way, there is a small thing that's itching me a bit about the > > change done in LogStandbySnapshot() for 105b2cb33617. Could it be > > useful for debugging to add a elog(DEBUG1) with the LSN returned by > > GetInsertRecPtr() when taking the short path? We don't have any > > visibility when the shortcut path is taken, which seems annoying in > > the long term if we use the injection point skip-log-running-xacts for > > other tests, and I suspect that there will be some as the standby > > snapshots can be really annoying in tests where we want a predictible > > set of WAL records when wal_level is "replica" or "logical". > > Yeah, I also think that would be good to have some way to debug this. > I can't think of a good reason to have this DEBUG1 as there is no predictability of it getting generated even with tests using an injection point. OTOH, I don't have any objections to it if you would like to proceed with this. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: