Re: wal_sender_delay is still required?

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

Fujii Masao <masao(dot)fujii(at)gmail(dot)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

On Tue, Dec 7, 2010 at 12:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

Fujii Masao <masao(dot)fujii(at)gmail(dot)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

Excerpts from Tom Lane's message of lun dic 06 23:49:52 -0300 2010:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

On Mon, Dec 6, 2010 at 10:07 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas <robertmhaas(at)gmail(dot)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

Alvaro Herrera <alvherre(at)commandprompt(dot)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

On 07.12.2010 05:51, Fujii Masao wrote:
> On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas<robertmhaas(at)gmail(dot)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