On Mon, Aug 23, 2021 at 12:54:58PM +0900, Masahiko Sawada wrote:
> On Sat, Aug 21, 2021 at 10:15 PM Gerard H. Pille <ghpille@hotmail.com> wrote:
>> The old thread:
>> https://postgrespro.com/list/thread-id/2337189#CAMkU=1wSxYBNFY9TzuVh3=mDLr4BBsMct6wcViNMH+-6Xon4Uw@mail.gmail.com
A link to postgresql.org does the same work:
https://www.postgresql.org/message-id/CAMkU=1wSxYBNFY9TzuVh3=mDLr4BBsMct6wcViNMH+-6Xon4Uw@mail.gmail.com
No need to redirect that elsewhere.
> 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?
Yeah. Honestly, I am not really excited to redesign this part of base
backups just to take care of a side problem that is mitigated for most
users with the use of a temporary slot. It would be simpler, as you
say, to find a way to detect if the slot wanted exists before even
launching START_REPLICATION with the specified slot on the second
thread copying the WAL, but that would be a new thing as one cannot do
catalog lookups with a physical replication session. Some ideas here
may be to extend the result of IDENTIFY_SYSTEM to return the slots
available in a text array, invent a new command called SLOT, use SHOW
or perhaps do an extra CREATE_REPLICATION_SLOT TEMPORARY from the main
thread.
--
Michael
