Re: Proposal: "Causal reads" mode for load balancing reads without stale data

On Fri, Mar 25, 2016 at 4:51 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Mar 24, 2016 at 12:34 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Wed, Mar 23, 2016 at 12:37 PM, Robert Haas <robertmhaas(at)gmail(dot)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