Re: [HACKERS] wal_sender_delay is still required?
On 07.12.2010 05:51, Fujii Masao wrote: On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
Alvaro Herrera 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
On Mon, Dec 6, 2010 at 10:07 PM, Fujii Masao wrote: > On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane wrote: >> Fujii Masao 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane wrote: > Fujii Masao 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
Excerpts from Tom Lane's message of lun dic 06 23:49:52 -0300 2010: > Fujii Masao 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 The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
Fujii Masao 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
On Tue, Dec 7, 2010 at 12:08 AM, Tom Lane wrote: > Fujii Masao 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 drop_wal_sender_delay_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wal_sender_delay is still required?
Fujii Masao 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
