| From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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-10 22:31:27 |
| Message-ID: | 8446d1c1-ace7-969a-1b8d-411cc3b081c9@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-11-10 22:51:34 | Something is broken about connection startup |
| Previous Message | Michael Paquier | 2016-11-10 22:06:42 | Re: WAL consistency check facility |