The thing I was trying to do was use the GUC hook function to make
sure that the required GUC variables are also set before GUC reports
autovac as enabled. This seemed cleaner to me, but apparently it
won't work since it seems that autovac_enabled is read from GUC
before the stats variables, and
Christopher Kings-Lynne wrote:
The thing I was trying to do was use the GUC hook function to make
sure that the required GUC variables are also set before GUC reports
autovac as enabled. This seemed cleaner to me, but apparently it
won't work since it seems that autovac_enabled is read from
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
Can we please have it default to enabled :)
We can but without also enabling statistics it will not work. Do we
want to enable both by default?
Weeell...it just seemed to me that we won't cut down on the support
mails unless it's on by default... I mean at some point in the future,
we WILL
Christopher Kings-Lynne wrote:
Can we please have it default to enabled :)
We can but without also enabling statistics it will not work. Do we
want to enable both by default?
Weeell...it just seemed to me that we won't cut down on the support
mails unless it's on by default... I
Matthew T. O'Connor [EMAIL PROTECTED] writes:
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.
GUC can't do that, but I think you can just hack the boolean variable
during startup --- compare what
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.
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I would think it would become default enabled someday. Should we
wait one release or do it for 7.5?
I think it's a bit premature to have it on by default, seeing that it's
still far from being in final form. In my mind it's still a pretty
Matthew, were are we on this patch?
---
Matthew T. O'Connor wrote:
FYI, I am out of town from Friday 7/2 till Monday evening 7/5. I
probably won't have email while I'm gone. I will continue working on
this when I get
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and makes
autovac fail more gracefully when the stats system is not enabled, but
that shouldn't
Matthew T. O'Connor wrote:
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and makes
autovac fail more gracefully when the stats system is
Matthew T. O'Connor wrote:
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and
makes autovac fail more gracefully when the stats system is
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. :-)
:-)
Bruce Momjian wrote:
I have added this patch plus your later comments to the patch queue.
The autovacuum process still uses libpq to send its queries, which is
not the idea behind backend integration.
Your patch has been added to the PostgreSQL unapplied patches list
at:
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have added this patch plus your later comments to the patch queue.
The autovacuum process still uses libpq to send its queries, which is
not the idea behind backend integration.
Can we consider this a non-fatal bug that has to be solved
Peter Eisentraut [EMAIL PROTECTED] writes:
The autovacuum process still uses libpq to send its queries, which is
not the idea behind backend integration.
Sure, but one step at a time. Getting it auto-launched from the
postmaster is already a good increment in usability, and offhand
I don't
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have added this patch plus your later comments to the patch queue.
The autovacuum process still uses libpq to send its queries, which is
not the idea behind backend integration.
Actually, I intentionally had pg_autovacuum continue to use libpq based
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Actually, I intentionally had pg_autovacuum continue to use libpq based
Tom's advise. Please see this thread:
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00931.php
And more specifically, these follow ups:
I have added this patch plus your later comments to the patch queue.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Is there someway to force the order in which variables are
read from GUC?
No.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
20 matches
Mail list logo
