On Fri, Mar 25, 2016 at 4:51 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, Mar 24, 2016 at 12:34 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Wed, Mar 23, 2016 at 12:37 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> +static void WalRcvUnblockSigUsr2(void) >>> >>> And again here. >> >> Fixed. >> >>> + WalRcvUnblockSigUsr2(); >>> len = walrcv_receive(NAPTIME_PER_CYCLE, &buf); >>> + WalRcvBlockSigUsr2(); >>> >>> This does not seem like it will be cheap on all operating systems. I >>> think you should try to rejigger this somehow so that it can just set >>> the process latch and the wal receiver figures it out from looking at >>> shared memory. Like maybe a flag in WalRcvData? An advantage of this >>> is that it should cut down on the number of signals significantly, >>> because it won't need to send SIGUSR1 when the latch is already set. >> >> Still experimenting with a latch here. I will come back on this point soon. > > Here is a latch-based version.
Thanks for the updated version. This looks pretty nice. I find the routine name libpqrcv_wait to be a bit confusing. This is not a routine aimed at being exposed externally as walrcv_send or walrcv_receive. I would recommend changing the name, to something like waitForWALStream or similar. Should we worried about potential backward-incompatibilities with the new return values of walrcv_receive? Do you have numbers to share regarding how is performing the latch-based approach and the approach that used SIGUSR2 when remote_apply is used? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers