Thread: pg_basebackup behavior on non-existent slot

On Tue, Sep 28, 2021 at 12:03 PM Dimitri Fontaine
<Dimitri.Fontaine@microsoft.com> wrote:
>
> Hi,
>
>
>
> When developing pg_auto_failover we found a bug where if the target replication slot given to pg_basebackup does not
exist,then a full copy of the source PGDATA is completed before erroring out. You could easily end-up copying 100GB of
dataover the network just to see pg_basebackup remove them all at the end, and then when using the –progress option,
youhave to scroll up to the very start of the output to see the error message. 
>
>
>
> Please find attached a patch that shows a way to fix the issue. The patch is missing windows compatibility, I don’t
knowhow to cast the WNOHANG spell on this platform. Please use the patch as you see fit, either inspiration, or maybe
somethingyou would like to commit to fix the bug. 
>
>
>
> Here what it looks like without the patch:
>
>
>
> $ ./src/bin/pg_basebackup/pg_basebackup -p 5501 -D /tmp/bb -X stream -S SlotDoesNotExists -P
>
> pg_basebackup: error: could not send replication command "START_REPLICATION": ERROR:  replication slot
"SlotDoesNotExists"does not exist 
>
> 32971/32971 kB (100%), 1/1 tablespace
>
> pg_basebackup: error: child process exited with exit code 1
>
> pg_basebackup: removing data directory "/tmp/bb"
>
>
>
>
>
> Here’s what it looks like with the patch applied locally:
>
>
>
> $ ./src/bin/pg_basebackup/pg_basebackup -p 5501 -D /tmp/bb -X stream -S SlotDoesNotExists -P
>
> pg_basebackup: error: could not send replication command "START_REPLICATION": ERROR:  replication slot
"SlotDoesNotExists"does not exist 
>
> pg_basebackup: error: child process exited with exit code 1
>
> pg_basebackup: removing data directory "/tmp/bb"

Isn't this solving basically the same thing as
https://commitfest.postgresql.org/34/3302/ (which does have Windows
support)? Does this implementations have some advantages over the one
Daniel posted, or should we just focus on that one since it does have
Windows support in it?

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

> On 28 Sep 2021, at 13:12, Dimitri Fontaine <Dimitri.Fontaine@microsoft.com> wrote:

> I think it’s safe to focus on Daniel’s entry in the commit fest,

For reference, here is the output from your testcase running with the
referenced patch:

$ ./bin/pg_basebackup -p 5432 -D /tmp/bb -X stream -S SlotDoesNotExists -P
pg_basebackup: error: could not send replication command "START_REPLICATION": ERROR:  replication slot
"SlotDoesNotExists"does not exist 
pg_basebackup: error: background WAL receiver terminated unexpectedly
pg_basebackup: removing data directory "/tmp/bb"

So this patch does seem to cover that case as well.

> and use this pgsql-bugs email as a reminder that it should very probably be backported as a bug-fix to all the
maintainedbranches. 

It probably should, I can't see anyone relying on the current behavior.  It's
however awfully intrusive for a backport as it effectively adds functionality
to solve what could be devils-advocate argued is an inconvenience and not a
bug.  Our conservative stance on backports make this not a clear-cut case, but
I'm interested in what others think here.

--
Daniel Gustafsson        https://vmware.com/