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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 21:19:23
Message-ID: AANLkTimava7fREnxkoThr9CYitG3HZNciR0tw8joVyGC@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Mar 18, 2011 at 2:55 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of vie mar 18 14:25:16 -0300 2011:
>> On Fri, Mar 18, 2011 at 1:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> > 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.
>
> Can't they both do it?

Yeah, but it seems fairly pointless.  In retrospect, I probably should
have done it the way Simon is proposing to begin with.

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

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-03-18 21:24:03
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Robert HaasDate: 2011-03-18 21:18:28
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

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