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.
This is the error that openjade produced:
openjade:ref/create_database.sgml:177:7:E: document type does not allow
element PARA here; missing one of FOOTNOTE, ITEMIZEDLIST,
ORDEREDLIST, VARIABLELIST, CAUTION, IMPORTANT, NOTE, TIP,
WARNING, BLOCKQUOTE, INFORMALEXAMPLE start-tag
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
Jonathan M. Gardner [EMAIL PROTECTED] writes:
openjade:ref/create_database.sgml:194:11:E: end tag for PARA omitted,
but OMITTAG NO was specified
openjade:ref/create_database.sgml:175:2: start tag was here
Yeah, I see it too on my RHL 8 machine. The DTD being used at
postgresql.org seems to
[ ... some desultory reading of PITR patch ... ]
What is the point of having both archive_program and archive_dest as
GUC variables? Wouldn't it be simpler to fold them into one parameter,
viz
archive_command = 'cp %s /archivedir'
For that matter, do we need a separate archive_mode
Tom Lane wrote:
[ ... some desultory reading of PITR patch ... ]
What is the point of having both archive_program and archive_dest as
GUC variables? Wouldn't it be simpler to fold them into one parameter,
viz
archive_command = 'cp %s /archivedir'
For that matter, do we need a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is a diff for subtransactions. I modified the SQL reference
section and touched on the various commands therein. I didn't mention
anything about cursors or portals, because I bet they will be resolved
before long.
I looked at the tutorial
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
What is the point of having both archive_program and archive_dest as
GUC variables?
I assume archive_dest is used for both archive and recovery of archives.
You assume wrong; it's not used there. There isn't any real good
reason to
Jonathan M. Gardner wrote:
Attached is a diff for subtransactions. I modified the SQL reference
section and touched on the various commands therein. I didn't mention
anything about cursors or portals, because I bet they will be
resolved before long.
It looks like you better wait until the
Jonathan M. Gardner [EMAIL PROTECTED] writes:
Attached is a diff for subtransactions.
Uh, I hate to tell you this, but you wasted your time because the syntax
accepted by CVS tip is not going to be the final syntax. None of what
you wrote here will be useful as soon as Alvaro's pending patch
The attached patch and additional src/backend/postmaster/syslogger.c
implements the logfile subprocess as discussed.
TODO:
- documentation
- win32 code (forkexec) is included, but not tested (no build env)
Functions (all are superuser only):
int4 pg_reload_conf()
Sends SIGHUP to postmaster
bool
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
What is the point of having both archive_program and archive_dest as
GUC variables?
I assume archive_dest is used for both archive and recovery of archives.
You assume wrong; it's not used there. There isn't any
Bruce Momjian wrote:
OK, the attached applied patch opens text files in binary mode in psql.
As you said, it already handles CRLF OK, and we need this to read
control-Z in copy files.
I assume we can write control-Z in text mode just fine, right?
I honestly don't know. Unless I see a
Ok, here is a new patch for to integrate pg_autovacuum into the backend.
This patch adds the following to that last patch:
* updated to latest CVS
* changed GUC vars from autovac_* to autovacuum_*
* changed autovac_enabled GUC variable to autovacuum
* changed autovacuum GUC variable default to
20 matches
Mail list logo
