Thread: 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.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
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
Attachment
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
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
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
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
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
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
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