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

On Thu, Mar 24, 2016 at 12:34 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Mar 23, 2016 at 12:37 PM, Robert Haas <robertmhaas@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.

On Thu, Mar 24, 2016 at 7:11 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Just looking at 0001.
>
> -        <literal>remote_write</>, <literal>local</>, and <literal>off</>.
> +        <literal>remote_write</>, <literal>remote_apply</>,
> <literal>local</>, and <literal>off</>.
>          The default, and safe, setting
> I imagine that a run of pgindent would be welcome for such large lines.

Fixed.

> +#define XactCompletionSyncApplyFeedback(xinfo) \
> +   (!!(xinfo & XACT_COMPLETION_SYNC_APPLY_FEEDBACK))
> That's not directly something this patch should take care of, but the
> notation "!!" has better be avoided (see stdbool thread with VS2015).

Changed.

> -   SyncRepWaitForLSN(gxact->prepare_end_lsn);
> +   SyncRepWaitForLSN(gxact->prepare_end_lsn, false);
> Isn't it important to ensure that a PREPARE LSN is applied as well on
> the standby with remote_apply? Say if an application prepares a
> transaction, it would commit locally but its LSN may not be applied on
> the standby with this patch. That would be a surprising behavior for
> the user.

My reasoning here was that this isn't a commit, so you shouldn't wait
for it to be applied (just like we don't wait for any other
non-committed stuff to be applied), because it has no user-visible
effect other than the ability to COMMIT PREPARED on the standby if it
is promoted after that point.  For that reason I do wait for it to be
flushed.  After it is flushed, it is guaranteed to be applied some
time before the recovery completes and a user could potentially run
COMMIT PREPARED on the newly promoted master.

--
Thomas Munro
http://www.enterprisedb.com