Skip site navigation (1) Skip section navigation (2)

Re: Sync Rep and shutdown Re: Sync Rep v19

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep and shutdown Re: Sync Rep v19
Date: 2011-03-18 17:25:16
Message-ID: AANLkTingUu=MXQcVJ5hx235OHfOdZwJhHCtnr+K37sYZ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Mar 18, 2011 at 1:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2011-03-17 at 09:33 -0400, Robert Haas wrote:
>> Thanks for the review!
>
> Lets have a look here...
>
> You've added a test inside the lock to see if there is a standby, which
> I took out for performance reasons. Maybe there's another way, I know
> that code is fiddly.
>
> You've also added back in the lock acquisition at wakeup with very
> little justification, which was a major performance hit.
>
> Together that's about a >20% hit in performance in Yeb's tests. I think
> you should spend a little time thinking how to retune that.

Ouch.  Do you have a link that describes his testing methodology?  I
will look at it.

> I see handling added for ProcDiePending and QueryCancelPending directly
> into syncrep.c without any comments in postgres.c to indicate that you
> bypass ProcessInterrupts() in some cases. That looks pretty hokey to me.

I can add some comments.  Unfortunately, it's not feasible to call
ProcessInterrupts() directly from this point in the code - it causes a
database panic.

> SyncRepUpdateSyncStandbysDefined() is added into walwriter, which means
> waiters won't be released if we do a sighup during a fast shutdown,
> since the walwriter gets killed as soon as that starts. I'm thinking
> bgwriter should handle that now.

Hmm.  I was thinking that doing it in WAL writer would make it more
responsive, but since this is a fairly unlikely scenario, it's
probably not worth complicating the shutdown sequence to do it the way
I did.  I'll move it to bgwriter.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2011-03-18 17:35:46
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Erik RijkersDate: 2011-03-18 17:19:49
Subject: pg_ctl restart - behaviour based on wrong instance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group