Re: Logical Replication WIP

From: Andres Freund <andres(at)anarazel(dot)de>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Steve Singer <steve(at)ssinger(dot)info>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical Replication WIP
Date: 2016-11-12 19:19:03
Message-ID: 20161112191903.xwrji5q7yqgjpxna@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-11-10 23:31:27 +0100, Petr Jelinek wrote:
> On 04/11/16 13:15, Andres Freund wrote:
> >
> > /* Prototypes for private functions */
> > -static bool libpq_select(int timeout_ms);
> > +static bool libpq_select(PGconn *streamConn,
> > + int timeout_ms);
> >
> > If we're starting to use this more widely, we really should just a latch
> > instead of the plain select(). In fact, I think it's more or less a bug
> > that we don't (select is only interruptible by signals on a subset of
> > our platforms). That shouldn't bother this patch, but...
> >
> >
>
> Agree that this is problem, especially for the subscription creation
> later. We should be doing WaitLatchOrSocket, but the question is which
> latch. We can't use MyProc one as that's not the latch that WalReceiver
> uses so I guess we would have to send latch as parameter to any caller
> of this which is not very pretty from api perspective but I don't have
> better idea here.

I think we should simply make walsender use the standard proc
latch. Afaics that should be fairly trivial?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-12 19:23:55 More snapshot-management fun
Previous Message Andres Freund 2016-11-12 19:18:25 Re: Logical Replication WIP