On 3 February 2016 at 10:46, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote > <langote_amit...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
