Re: Proposal: "Causal reads" mode for load balancing reads without stale data - Mailing list pgsql-hackers

From Thom Brown
Subject Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Date
Msg-id CAA-aLv7sOFOAK4C9FFeQ07gQhEgETkjoc-_WotXVDg3NKC-oKQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: "Causal reads" mode for load balancing reads without stale data  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Proposal: "Causal reads" mode for load balancing reads without stale data
List pgsql-hackers
On 3 February 2016 at 10:46, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> There seems to be a copy-pasto there - shouldn't that be:
>>
>> + if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH] < MyWalSnd->flush)
>
> Indeed, thanks!  New patch attached.

I've given this a test drive, and it works exactly as described.

But one thing which confuses me is when a standby, with causal_reads
enabled, has just finished starting up.  I can't connect to it
because:

FATAL:  standby is not available for causal reads

However, this is the same message when I'm successfully connected, but
it's lagging, and the primary is still waiting for the standby to
catch up:

ERROR:  standby is not available for causal reads

What is the difference here?  The problem being reported appears to be
identical, but in the first case I can't connect, but in the second
case I can (although I still can't issue queries).

Thom



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: checkpointer continuous flushing - V18
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.