Horton

Thread

  1. wal_sender_delay is still required?

    Fujii Masao <masao.fujii@gmail.com> — 2010-12-06T08:13:10Z

    Hi,

Walsender doesn't need the periodic wakeups anymore, thanks to
the latch feature. So wal_sender_delay is basically useless now.
How about dropping wal_sender_delay or increasing the default
value?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

  2. Re: wal_sender_delay is still required?

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-12-06T15:08:21Z

    Fujii Masao <masao.fujii@gmail.com> writes:
> Walsender doesn't need the periodic wakeups anymore, thanks to
> the latch feature. So wal_sender_delay is basically useless now.
> How about dropping wal_sender_delay or increasing the default
> value?

If we don't need it, we should remove it.

			regards, tom lane

  3. Re: wal_sender_delay is still required?

    Fujii Masao <masao.fujii@gmail.com> — 2010-12-07T02:37:25Z

    On Tue, Dec 7, 2010 at 12:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> Walsender doesn't need the periodic wakeups anymore, thanks to
>> the latch feature. So wal_sender_delay is basically useless now.
>> How about dropping wal_sender_delay or increasing the default
>> value?
>
> If we don't need it, we should remove it.

The attached patch removes wal_sender_delay and uses hard-coded
10 seconds instead of wal_sender_delay as the delay between activity
rounds for walsender.

One problem with the patch is that it takes longer (at most 10s) to
detect the unexpected death of postmaster (by calling PostmasterIsAlive()).
This is OK for me. But does anyone want to specify the delay to detect
that within a short time?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

  4. Re: wal_sender_delay is still required?

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-12-07T02:49:52Z

    Fujii Masao <masao.fujii@gmail.com> writes:
> One problem with the patch is that it takes longer (at most 10s) to
> detect the unexpected death of postmaster (by calling PostmasterIsAlive()).
> This is OK for me. But does anyone want to specify the delay to detect
> that within a short time?

Oh.  Hm.  I'm hesitant to remove the setting if there's still some
behavior that it would control.  Maybe we should just crank up the
default value instead.

			regards, tom lane

  5. Re: wal_sender_delay is still required?

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-12-07T03:02:00Z

    Excerpts from Tom Lane's message of lun dic 06 23:49:52 -0300 2010:
> Fujii Masao <masao.fujii@gmail.com> writes:
> > One problem with the patch is that it takes longer (at most 10s) to
> > detect the unexpected death of postmaster (by calling PostmasterIsAlive()).
> > This is OK for me. But does anyone want to specify the delay to detect
> > that within a short time?
> 
> Oh.  Hm.  I'm hesitant to remove the setting if there's still some
> behavior that it would control.  Maybe we should just crank up the
> default value instead.

Maybe we should have a single tunable for processes that just sleep
waiting for events or postmaster death.  For example pgstats has a
hardcoded 2 seconds, and the archiver process has a hardcoded value too
AFAICS.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

  6. Re: wal_sender_delay is still required?

    Fujii Masao <masao.fujii@gmail.com> — 2010-12-07T03:07:20Z

    On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> One problem with the patch is that it takes longer (at most 10s) to
>> detect the unexpected death of postmaster (by calling PostmasterIsAlive()).
>> This is OK for me. But does anyone want to specify the delay to detect
>> that within a short time?
>
> Oh.  Hm.  I'm hesitant to remove the setting if there's still some
> behavior that it would control.  Maybe we should just crank up the
> default value instead.

Fair enough. How about increasing the default to 10 seconds?
Since bgwriter has already using 10s as a nap time if there is no
configured activity, I think that 10s is non-nonsense default value.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

  7. Re: wal_sender_delay is still required?

    Robert Haas <robertmhaas@gmail.com> — 2010-12-07T03:22:57Z

    On Mon, Dec 6, 2010 at 10:07 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Fujii Masao <masao.fujii@gmail.com> writes:
>>> One problem with the patch is that it takes longer (at most 10s) to
>>> detect the unexpected death of postmaster (by calling PostmasterIsAlive()).
>>> This is OK for me. But does anyone want to specify the delay to detect
>>> that within a short time?
>>
>> Oh.  Hm.  I'm hesitant to remove the setting if there's still some
>> behavior that it would control.  Maybe we should just crank up the
>> default value instead.
>
> Fair enough. How about increasing the default to 10 seconds?
> Since bgwriter has already using 10s as a nap time if there is no
> configured activity, I think that 10s is non-nonsense default value.

What do we get out of making this non-configurable?

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

  8. Re: wal_sender_delay is still required?

    Fujii Masao <masao.fujii@gmail.com> — 2010-12-07T03:51:58Z

    On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Fair enough. How about increasing the default to 10 seconds?
>> Since bgwriter has already using 10s as a nap time if there is no
>> configured activity, I think that 10s is non-nonsense default value.
>
> What do we get out of making this non-configurable?

Which would make the setting of replication simpler, I think.
But I agree to just increase the default value of wal_sender_delay
rather than dropping it.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

  9. Re: wal_sender_delay is still required?

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-12-07T05:22:14Z

    Alvaro Herrera <alvherre@commandprompt.com> writes:
> Maybe we should have a single tunable for processes that just sleep
> waiting for events or postmaster death.  For example pgstats has a
> hardcoded 2 seconds, and the archiver process has a hardcoded value too
> AFAICS.

That would make sense once we get to the point where for all of those
processes, the sleep delay *only* affects the time to notice postmaster
death.  Right now I think there are still several other behaviors mixed
in with that, and not all of them necessarily want the same response
time.

			regards, tom lane

  10. Re: wal_sender_delay is still required?

    Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-02-26T21:12:59Z

    On 07.12.2010 05:51, Fujii Masao wrote:
> On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas<robertmhaas@gmail.com>  wrote:
>>> Fair enough. How about increasing the default to 10 seconds?
>>> Since bgwriter has already using 10s as a nap time if there is no
>>> configured activity, I think that 10s is non-nonsense default value.
>>
>> What do we get out of making this non-configurable?
>
> Which would make the setting of replication simpler, I think.
> But I agree to just increase the default value of wal_sender_delay
> rather than dropping it.

I dropped the ball on this one..

For comparison, the archiver process and autovacuum launcher wake up 
once a second to check if postmaster is still alive. bgwriter, when 
bgwriter_lru_maxpages and archive_timeout are set to 0 to disable it, 
checks for dead postmaster every 10 seconds.

I'll bump the default for wal_sender_delay to 1 second. Maybe an even 
higher value would be good, but it also seems good to kill replication 
connections in a timely fashion if postmaster dies.

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