Re: pg_basebackup behavior on non-existent slot - Mailing list pgsql-bugs

From Masahiko Sawada
Subject Re: pg_basebackup behavior on non-existent slot
Date
Msg-id CAD21AoA=D1ssWr-GOPz-NMr4jDsZb2VGetdRVvXeQXtdiLoBUA@mail.gmail.com
Whole thread Raw
In response to pg_basebackup behavior on non-existent slot  ("Gerard H. Pille" <ghpille@hotmail.com>)
Responses Re: pg_basebackup behavior on non-existent slot  (Michael Paquier <michael@paquier.xyz>)
Re: pg_basebackup behavior on non-existent slot  ("Gerard H. Pille" <ghpille@hotmail.com>)
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: BUG #17070: Sometimes copy from ingnores transaction
Next
From: Michael Paquier
Date:
Subject: Re: pg_basebackup behavior on non-existent slot