Re: pgsql: Prevent invalidation of newly synced replication slots.
| От | Andres Freund |
|---|---|
| Тема | Re: pgsql: Prevent invalidation of newly synced replication slots. |
| Дата | |
| Msg-id | y2tddikdvhr47nkybp457l7czr5alsosx2237n2eb4jkpcj4hr@wygnzz3kpqxl обсуждение исходный текст |
| Ответ на | Re: pgsql: Prevent invalidation of newly synced replication slots. (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: pgsql: Prevent invalidation of newly synced replication slots.
Re: pgsql: Prevent invalidation of newly synced replication slots. |
| Список | pgsql-hackers |
Hi, On 2026-01-27 12:42:51 -0500, Robert Haas wrote: > I tried sticking a pg_sleep(30) in just before starting the standby > node, and that didn't help, so it doesn't seem like it's a race > condition. Interesting. It could be worth trying to run the test in isolation, without all the other concurrent tests. Greg, have you tried to repro it interactively? Bryan, you seem to have become the resident windows expert... > 2026-01-27 17:19:25.337 GMT startup[2488] LOG: starting backup > recovery with redo LSN 0/2A000028, checkpoint LSN 0/2A000080, on > timeline ID 1 > The system cannot find the file specified. > 2026-01-27 17:19:25.352 GMT startup[2488] DEBUG: could not restore > file "00000001000000000000002A" from archive: child process exited > with exit code 1 I think that must be a message from "copy" (which we seem to be using for restore_command on windows). I don't know why the standby is created with has_restoring => 1. But it shouldn't be related to the issue, I think? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: