On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs <si...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
