Re: [HACKERS] Re: [GENERAL] pg_basebackup error: replication slot"pg_basebackup_2194" already exists
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Re: [GENERAL] pg_basebackup error: replication slot"pg_basebackup_2194" already exists |
Дата | |
Msg-id | CAB7nPqS0z5seabtVZfDeuRzYyxwx2E+r4mjAM7G5+ks0FcP45Q@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Re: [GENERAL] pg_basebackup error: replication slot"pg_basebackup_2194" already exists (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On Wed, May 31, 2017 at 9:22 AM, Magnus Hagander <magnus@hagander.net> wrote: > Moving this one over to -hackers to discuss the fix, as this is clearly an > issue. > > Right now, pg_basebackup will use the pid of the *client* process to > generate it's ephemeral slot name. Per this report that seems like it can > definitely be a problem. > > One of my first thoughts would be to instead use the pid of the *server* to > do that, as this will be guaranteed to be unique. However, the client can't > access the pid of the server as it is now, and its the client that has to > create the name. Yes, something like that sounds like a sensible idea. The system identifier won't help either. > One way to do that would be to include the pid of the walsender backend in > the reply to IDENTIFY_SYSTEM, and then use that. What do people think of > that idea? > > Other suggestions? Here is a funky idea: add a read-only GUC parameter that reports the PID of the process, and use the SHOW command with the replication protocol to get the PID on backend-side. -- Michael
В списке pgsql-hackers по дате отправления: