On Wed, May 31, 2017 at 8:18 PM, Andres Freund wrote:
> On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
> > 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.
>
> I don't think that's actually true? Doesn't the wire proto
On Wed, May 31, 2017 at 11:18 AM, Andres Freund wrote:
> On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
>> 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.
>
> I don't think that's actually true? Doesn't the wire protoco
On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
> 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.
I don't think that's actually true? Doesn't the wire protocol always
include the PID, which is then exposed with PQbackendP
On Wed, May 31, 2017 at 9:22 AM, Magnus Hagander 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
> defin
On Wed, May 31, 2017 at 12:20 AM, Ludovic Vaugeois-Pepin <
ludovi...@gmail.com> wrote:
> On Tue, May 30, 2017 at 9:32 PM, Magnus Hagander
> wrote:
> > On Tue, May 30, 2017 at 9:14 PM, Ludovic Vaugeois-Pepin
> > wrote:
> >>
> >> I ran into the issue described below with 10.0 beta. The error I got
