Re: [EXTERNAL] pg_basebackup behavior on non-existent slot

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Dimitri Fontaine <Dimitri(dot)Fontaine(at)microsoft(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: [EXTERNAL] pg_basebackup behavior on non-existent slot
Date: 2021-09-29 09:24:08
Message-ID: A2188D8C-757C-48C3-9C28-B7882BE7F051@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 28 Sep 2021, at 13:12, Dimitri Fontaine <Dimitri(dot)Fontaine(at)microsoft(dot)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 maintained branches.

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/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-09-29 13:36:01 Re: BUG #17203: missing websearch_to_tsquery
Previous Message PG Bug reporting form 2021-09-29 03:09:24 BUG #17203: missing websearch_to_tsquery