Subject: Re: Sync Rep for 2011CF1
From: Simon Riggs <simon@2ndQuadrant.com>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <AANLkTikFzAgjpiM6KsfGt-u4j8SE5C76-d+BFhzkAXd2@mail.gmail.com>
References: <1295127631.3282.100.camel@ebony>
	<AANLkTikFzAgjpiM6KsfGt-u4j8SE5C76-d+BFhzkAXd2@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 15 Feb 2011 16:29:28 +0000
Message-ID: <1297787368.1747.21355.camel@ebony>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > Here's the latest patch for sync rep.
> >
> 
> I was looking at this code and found something in SyncRepWaitOnQueue
> we declare a timeout variable that is a long and another that is a
> boolean (this last one in the else part of the "if
> (!IsOnSyncRepQueue())"), and then use the boolean one as if it were
> the long one

OK, thanks.

> +       else
> +       {
> +           bool release = false;
> +           bool timeout = false;
> +
> +           SpinLockAcquire(&queue->qlock);
> +
> +           /*
> +            * Check the LSN on our queue and if its moved far enough then
> +            * remove us from the queue. First time through this is
> +            * unlikely to be far enough, yet is possible. Next time we are
> +            * woken we should be more lucky.
> +            */
> +           if (XLByteLE(XactCommitLSN, queue->lsn))
> +               release = true;
> +           else if (timeout > 0 &&
> +               TimestampDifferenceExceeds(GetCurrentTransactionStopTimestamp(),
> +                                       now,
> +                                       timeout))
> +           {
> +               release = true;
> +               timeout = true;
> +           }
> 
> the other two things are on postgresql.conf.sample:
> - we have two replication_timeout_client, obviously one of them should
> be replication_timeout_server
> - synchronous_replication_feedback is off by default, but docs says otherwise
> 
> i also have been testing this, until now the only issue i have found
> is that if i set allow_standalone_primary to off and there isn't a
> standby connected i need to stop the server with -m immediate which is
> at least surprising

I think that code is being ripped out, so will check again later.

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services