Re: pgsql: Prevent invalidation of newly synced replication slots.
| От | Robert Haas |
|---|---|
| Тема | Re: pgsql: Prevent invalidation of newly synced replication slots. |
| Дата | |
| Msg-id | CA+TgmobXMhXFYM=mJ51f5PRFuj7eR9zn68Bvjndjz-k+daSotg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgsql: Prevent invalidation of newly synced replication slots. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Tue, Jan 27, 2026 at 11:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > What's also puzzling is that what this test is doing seems to be > > totally standard. > > Yeah. I do notice something interesting when running it here: > 046_checkpoint_logical_slot_mike.log shows that we are triggering > quite a few checkpoints (via pg_switch_wal()) in quick succession > on the primary. I wonder if that is somehow tickling a Windows > filesystem restriction. Maybe, but it seems unlikely to me that this would mess up the standby, since it's a totally different node. What I kind of wonder is if somehow there's still a process that has backup_label open, or has closed it but not recently enough for Windows to unlock it. However, I don't see why that would affect this test case and not others. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: