Re: pg_basebackup behavior on non-existent slot
От | Masahiko Sawada |
---|---|
Тема | Re: pg_basebackup behavior on non-existent slot |
Дата | |
Msg-id | CAD21AoA=D1ssWr-GOPz-NMr4jDsZb2VGetdRVvXeQXtdiLoBUA@mail.gmail.com обсуждение исходный текст |
Ответ на | pg_basebackup behavior on non-existent slot ("Gerard H. Pille" <ghpille@hotmail.com>) |
Ответы |
Re: pg_basebackup behavior on non-existent slot
Re: pg_basebackup behavior on non-existent slot |
Список | pgsql-bugs |
Hi, On Sat, Aug 21, 2021 at 10:15 PM Gerard H. Pille <ghpille@hotmail.com> wrote: > > Hallo, > > I was just confronted with this behaviour described back in 2017, and > the participants in the thread seem to consider it a bug. But I'm > running on version 13. So, how did that discussion end? > > My case: > @ pg_basebackup -h 192.168.1.131 -D $PWD/13/main -U repuser -v -P -S stream > Password: > pg_basebackup: initiating base backup, waiting for checkpoint to complete > pg_basebackup: checkpoint completed > pg_basebackup: write-ahead log start point: 23/4E000028 on timeline 1 > pg_basebackup: starting background WAL receiver > pg_basebackup: error: could not send replication command > "START_REPLICATION": ERROR: replication slot "stream" does not exist > 53790996/53790996 kB (100%), 2/2 tablespaces > > pg_basebackup: write-ahead log end point: 23/4E000138 > pg_basebackup: waiting for background process to finish streaming ... > pg_basebackup: error: child process exited with exit code 1 > pg_basebackup: removing data directory "/var/lib/postgresql/13/main" > pg_basebackup: changes to tablespace directories will not be undone > > The old thread: > https://postgrespro.com/list/thread-id/2337189#CAMkU=1wSxYBNFY9TzuVh3=mDLr4BBsMct6wcViNMH+-6Xon4Uw@mail.gmail.com It seems it's not fixed yet even in HEAD as far as I tested. There were some ideas to fix that on that thread but the main point was how to fix it on Windows. I guess that since it creates a transient slot it’s not a common case to specify a non-existence slot in pg_baseback but what is your use case? This might help motivate to fix this issue. BTW in that thread, there was a discussion on how to detect the streamer process failure in the main process but probably we can fix this by just doing an existence check for the specified name replication slot before starting the streamer process? Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
В списке pgsql-bugs по дате отправления: