Re: [HACKERS] [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Can you make 0 and -1 both valid disabled values? That way it will be
compatible with previous releases.
Heh, sure, we can do that too and it doesn't seem like anybody would
object. I will patch the documentation so that that the disabled
value is zero, and still allow -1. That way it doesn't seem like there
should be any objection.
Patch attached.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Saca el libro que tu religión considere como el indicado para encontrar la
oración que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona (Carlos Duclós)
Index: doc/src/sgml/catalogs.sgml
===
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.153
diff -c -p -r2.153 catalogs.sgml
*** doc/src/sgml/catalogs.sgml 5 Jun 2007 21:31:03 - 2.153
--- doc/src/sgml/catalogs.sgml 8 Jun 2007 14:40:10 -
***
*** 1339,1347
be used for this particular value. Observe that the
structfieldvac_cost_delay/ variable inherits its default value from the
xref linkend=guc-autovacuum-vacuum-cost-delay configuration parameter,
!or from varnamevacuum_cost_delay/ if the former is set to a negative
!value. The same applies to structfieldvac_cost_limit/.
!Also, autovacuum will ignore attempts to set a per-table
structfieldfreeze_max_age/ larger than the system-wide setting (it can only be set
smaller), and the structfieldfreeze_min_age value/ will be limited to half the
system-wide xref linkend=guc-autovacuum-freeze-max-age setting.
--- 1339,1350
be used for this particular value. Observe that the
structfieldvac_cost_delay/ variable inherits its default value from the
xref linkend=guc-autovacuum-vacuum-cost-delay configuration parameter,
!or from xref linkend=guc-vacuum-cost-delay if the former is set to a negative
!value. structfieldvac_cost_limit/ is an exception to this rule, because
!the value literal0/ is used to indicate that the
!xref linkend=guc-autovacuum-vacuum-cost-limit configuration parameter
!should be used, or xref linkend=guc-vacuum-cost-limit if the former is set to a
!zero or negative value. Note that autovacuum will ignore attempts to set a per-table
structfieldfreeze_max_age/ larger than the system-wide setting (it can only be set
smaller), and the structfieldfreeze_min_age value/ will be limited to half the
system-wide xref linkend=guc-autovacuum-freeze-max-age setting.
Index: doc/src/sgml/config.sgml
===
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.126
diff -c -p -r1.126 config.sgml
*** doc/src/sgml/config.sgml 7 Jun 2007 19:19:56 - 1.126
--- doc/src/sgml/config.sgml 8 Jun 2007 14:15:33 -
*** SELECT * FROM parent WHERE key = 2400;
*** 3356,3362
listitem
para
Specifies the cost limit value that will be used in automatic
! commandVACUUM/ operations. If literal-1/ is specified (which is the
default), the regular
xref linkend=guc-vacuum-cost-limit value will be used. Note that
the value is distributed proportionally among the running autovacuum
--- 3356,3362
listitem
para
Specifies the cost limit value that will be used in automatic
! commandVACUUM/ operations. If literal0/ is specified (which is the
default), the regular
xref linkend=guc-vacuum-cost-limit value will be used. Note that
the value is distributed proportionally among the running autovacuum
Index: src/backend/postmaster/autovacuum.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.47
diff -c -p -r1.47 autovacuum.c
*** src/backend/postmaster/autovacuum.c 30 May 2007 20:11:57 - 1.47
--- src/backend/postmaster/autovacuum.c 8 Jun 2007 14:23:35 -
*** static void
*** 1548,1554
autovac_balance_cost(void)
{
WorkerInfo worker;
! int vac_cost_limit = (autovacuum_vac_cost_limit = 0 ?
autovacuum_vac_cost_limit : VacuumCostLimit);
int vac_cost_delay = (autovacuum_vac_cost_delay = 0 ?
autovacuum_vac_cost_delay : VacuumCostDelay);
--- 1548,1554
autovac_balance_cost(void)
{
WorkerInfo worker;
! int vac_cost_limit = (autovacuum_vac_cost_limit 0 ?
autovacuum_vac_cost_limit : VacuumCostLimit);
int vac_cost_delay = (autovacuum_vac_cost_delay = 0 ?
autovacuum_vac_cost_delay : VacuumCostDelay);
*** table_recheck_autovac(Oid relid)
*** 2143,2151
*/
if (avForm != NULL)
{
! vac_cost_limit =
Re: [HACKERS] [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Alvaro Herrera [EMAIL PROTECTED] writes: Matthew T. O'Connor wrote: Can you make 0 and -1 both valid disabled values? That way it will be compatible with previous releases. Heh, sure, we can do that too and it doesn't seem like anybody would object. I will patch the documentation so that that the disabled value is zero, and still allow -1. That way it doesn't seem like there should be any objection. Patch attached. It seems like documenting vac_cost_limit as being different from the others will just create perceived complexity/confusion, with no real benefit. I'd suggest leaving the documentation and the default value alone, and applying just the part of the patch that causes 0 to be silently treated as if it were -1. A comment at the spot where this is done would be a good idea, but I don't think we need to say anything in the SGML docs. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: But this is misleading (started postmaster with good value, then edited postgresql.conf and entered -2): 17903 LOG: received SIGHUP, reloading configuration files 17903 LOG: -2 is outside the valid range for parameter autovacuum_vacuum_cost_limit (-1 .. 1000) Note how it still says the range is -1 .. 1000. Can we redefine things to make zero be the disabled value, thus keeping the range of valid values contiguous? That would be another solution ... though it would be different from the valid value for autovacuum_vacuum_cost_delay (on which 0 is a valid value). Also it would be a different value from previous versions. I don't think either of these is a showstopper, so let's go for that if nobody objects. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ inflex really, I see PHP as like a strange amalgamation of C, Perl, Shell crab inflex: you know that amalgam means mixture with mercury, more or less, right? crab i.e., deadly poison ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: But this is misleading (started postmaster with good value, then edited postgresql.conf and entered -2): 17903 LOG: received SIGHUP, reloading configuration files 17903 LOG: -2 is outside the valid range for parameter autovacuum_vacuum_cost_limit (-1 .. 1000) Note how it still says the range is -1 .. 1000. Can we redefine things to make zero be the disabled value, thus keeping the range of valid values contiguous? That would be another solution ... though it would be different from the valid value for autovacuum_vacuum_cost_delay (on which 0 is a valid value). Also it would be a different value from previous versions. I don't think either of these is a showstopper, so let's go for that if nobody objects. Can you make 0 and -1 both valid disabled values? That way it will be compatible with previous releases. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Matthew T. O'Connor wrote: Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: But this is misleading (started postmaster with good value, then edited postgresql.conf and entered -2): 17903 LOG: received SIGHUP, reloading configuration files 17903 LOG: -2 is outside the valid range for parameter autovacuum_vacuum_cost_limit (-1 .. 1000) Note how it still says the range is -1 .. 1000. Can we redefine things to make zero be the disabled value, thus keeping the range of valid values contiguous? That would be another solution ... though it would be different from the valid value for autovacuum_vacuum_cost_delay (on which 0 is a valid value). Also it would be a different value from previous versions. I don't think either of these is a showstopper, so let's go for that if nobody objects. Can you make 0 and -1 both valid disabled values? That way it will be compatible with previous releases. Heh, sure, we can do that too and it doesn't seem like anybody would object. I will patch the documentation so that that the disabled value is zero, and still allow -1. That way it doesn't seem like there should be any objection. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ Escucha y olvidarás; ve y recordarás; haz y entenderás (Confucio) ---(end of broadcast)--- TIP 6: explain analyze is your friend
