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

Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per
Date: 2010-04-06 13:01:29
Message-ID: 4BBB30A9.2070605@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs wrote:
> On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
>>>> Fujii Masao wrote:
>>>>> On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>>>> I was also surprised to note that the Startup process is not signaled by
>>>>>> WALReceiver when new WAL is received, so it will continue sleeping even
>>>>>> though it has work to do.
>>>>> I don't think this is so useful in 9.0 since synchronous replication
>>>>> (i.e., transaction commit wait for WAL to be replayed by the standby)
>>>>> is not supported.
>>>> Well, it would still be useful, as it would shorten the delay. But yeah,
>>>> there's a delay in asynchronous replication anyway, so we decided to
>>>> keep it simple and just poll. It's not ideal and definitely needs to be
>>>> revisited for synchronous mode in the future. Same for walsenders.
>>> A signal seems fairly straightforward to me, the archiver did this in
>>> 8.0 and it was not considered complex then. Quite why it would be
>>> complex here is not clear.
>> The other side of the problem is that walsender polls too. Eliminating
>> the delay from walreceiver doesn't buy you much unless you eliminate the
>> delay from the walsender too. And things get complicated there. Do you
>> signal the walsenders at every commit? That would be a lot of volume,
>> and adds more work for every normal transaction in the primary. Maybe
>> not much, but it would be one more thing to worry about and test.
> 
> You are trying to connect two unrelated things.
> 
> We can argue that the WALSender's delay allows it to build up a good
> sized batch of work to transfer.
> 
> Having the Startup process wait does not buy us anything at all.
> Currently if the Startup process finishes more quickly than the
> WALreceiver it will wait for 100ms.

Ok, here's a patch to add signaling between walreceiver and startup
process. It indeed isn't much code, and seems pretty safe, so if no-one
objects strongly, I'll commit. It won't help on platforms where
pg_usleep() isn't interrupted by signals, though, but we can live with that.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Attachment: signal-startupproc-on-walreceive-1.patch
Description: text/x-diff (3.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2010-04-06 13:07:06
Subject: Re: SELECT constant; takes 15x longer on 9.0?
Previous:From: Fujii MasaoDate: 2010-04-06 12:25:49
Subject: Re: walreceiver is uninterruptible on win32

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-04-06 13:15:53
Subject: Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per
Previous:From: Robert HaasDate: 2010-04-06 12:09:37
Subject: Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per

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