From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: pg_autovacuum integration attempt #2 |
Date: | 2004-07-17 10:50:06 |
Message-ID: | 200407171050.i6HAo6429534@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Matthew T. O'Connor wrote:
> On Fri, 2004-07-16 at 17:13, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > A nitpick on that parameter name: There is not reason to abbreviate
> > > "autovacuum": there is enough space. And the "_enabled" is redundant.
> >
> > Agreed. Nitpicks are important too because it makes us so beautiful. :-)
>
> :-) I'll make that change.
>
> > > What I am missing at least is what you really mean by "the required GUC
> > > variables are also set". GUC variables are always set to something (at
> > > least after the initialization phase, but you don't get to do anything
> > > with GUC before the initialization, obviously).
> >
> > He means he has to have the stats collector enabled along with
> > autovacuum, and he doesn't have a way to effectively test that stats are
> > enabled when enabling autovacuum because the ordering of postgresql.conf
> > variable loads isn't predefined.
>
> Exactly. However, I can work around the GUC ordering issue just by
> having the postmaster check all the required variables before launching
> autovac. What I wanted to do was have GUC prevent autovacuum = true
> when the stats collector is not enabled, reguardless of what is in
> postgresql.conf.
Yes, that's what I would do. Agreed it would be nice to report the
failure during SET though, but I can't think of a way to do that.
You are actually showing a general limitation of checking GUC variable
interactions. For example, I now see that my assign_log_stats() is
wrong because if you enable one of the parameters in the postgresql.conf
file, and then disable one and enable another, the reload might not work
depending on the order they appear in the file.
I wonder if we need to have some function to check the state of variable
interactions after the file is processed and after other groupings like
user/database settings.
We can deal with this later, of course, but it is clearly a limitation
of our current system. Added to TODO:
o Enforce rules for setting combinations
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-07-17 10:50:43 | Re: pg_autovacuum integration attempt #2 |
Previous Message | Christopher Kings-Lynne | 2004-07-17 10:01:54 | Re: pg_autovacuum integration attempt #2 |