Ready for Beta ... ?
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?
Speak now, or forever hold your piece :)
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Speak now, or forever hold your piece :)
The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.
---------------------------------------------------------------------------
P O S T G R E S Q L
8 . 0 O P E N I T E M S
Current version at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
-------
* Win32
o binary version stamps
o signal safe socket handler
o query cancel in psql (?)
o Report correct errno codes from native Windows system calls
o Shorten timezone for %t log_line_prefix
o start pg_autovacuum easily
o fix pitr file copy syntax
* fix dbsize and oid2name for tablespaces
* allow libpq to check parameterized data types
* make pgxs install the default
* add xid to log_line_prefix for PITR
* add psql tab completion for tablespaces
* cleanup FRONTEND use in /port, malloc, elog
* disable vacuum delay?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073pgman wrote:
Marc G. Fournier wrote:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Speak now, or forever hold your piece :)
The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.
OK, I think Jan agreed not to have vacuum delay enabled by default so I
backed out his patch to it is now disabled.
Patch attached and applied.
I think this means we are ready for beta1.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/bjm/difftext/plainDownload
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.227
retrieving revision 1.228
diff -c -c -r1.227 -r1.228
*** src/backend/utils/misc/guc.c 6 Aug 2004 04:15:09 -0000 1.227
--- src/backend/utils/misc/guc.c 7 Aug 2004 03:08:44 -0000 1.228
***************
*** 1046,1052 ****
NULL
},
&VacuumCostDelay,
! 0, 0, 1000, NULL, NULL
},
{
--- 1046,1052 ----
NULL
},
&VacuumCostDelay,
! 50, 0, 1000, NULL, NULL
},
{
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.121
retrieving revision 1.122
diff -c -c -r1.121 -r1.122
*** src/backend/utils/misc/postgresql.conf.sample 7 Aug 2004 01:04:50 -0000 1.121
--- src/backend/utils/misc/postgresql.conf.sample 7 Aug 2004 03:08:49 -0000 1.122
***************
*** 74,80 ****
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits
! #vacuum_cost_delay = 0 # 0-1000 milliseconds
# - Background writer -
#bgwriter_delay = 200 # 10-5000 milliseconds
--- 74,80 ----
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits
! #vacuum_cost_delay = 50 # 0-1000 milliseconds
# - Background writer -
#bgwriter_delay = 200 # 10-5000 milliseconds
Import Notes
Reply to msg id not found: | Resolved by subject fallback
Andreas Pflug wrote:
Bruce Momjian wrote:
Marc G. Fournier wrote:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Speak now, or forever hold your piece :)
Well, there's the logfile rotation issue...
With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.
The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.I hereby report Win32 as building good :-)
The former confusion was caused by me, doing the bloody "failed to make
distclean" mistake.
No problem. I disabled vacuum delay so we are ready to go!
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 4116651E.6090505@pse-consulting.de | Resolved by subject fallback
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.
regards, tom lane
Andreas Pflug wrote:
Bruce Momjian wrote:
Well, there's the logfile rotation issue...
With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.
Adding a function will require a system catalog change. If we are
already doing one we might be able to get it in, but I doubt it greatly.
We already do more than rotatelogs by specifying a size. That seems
enough to me for now.
Basically I think you will need a vote to expand this in 8.1.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 411668FD.2040501@pse-consulting.de | Resolved by subject fallback
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.
Done.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073"Marc G. Fournier" <scrappy@postgresql.org> writes:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?
Looks good from here. I plan to spend the afternoon doing docs work,
not touching any code unless some last-minute bug report shows up.
regards, tom lane
Tom Lane wrote:
"Marc G. Fournier" <scrappy@postgresql.org> writes:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Looks good from here. I plan to spend the afternoon doing docs work,
not touching any code unless some last-minute bug report shows up.
Good. I am heading out. My cell is 610-742-9657 if anyone wants me.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote:
Marc G. Fournier wrote:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Speak now, or forever hold your piece :)
Well, there's the logfile rotation issue...
The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.
I hereby report Win32 as building good :-)
The former confusion was caused by me, doing the bloody "failed to make
distclean" mistake.
Regards,
Andreas
Bruce Momjian wrote:
Well, there's the logfile rotation issue...
With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.
How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.
You can always find a program that doesn't support a specific feature.
And pgsql is probably more comparable to MSSQL, which has it, than to
Apache's rotatelogs, which doesn't even support size triggering.
Omitting the handler will not even leave a chance to implement an add-on
function.
Regards,
Andreas
Bruce Momjian wrote:
How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.Adding a function will require a system catalog change.
Not necessarily. pg_logdir_ls is not included either, so pgadmin already
needs an additional module to handle the logfiles. Handling
pg_logfile_rotate the same isn't a problem. But if the logger is
autistic and unable to handle a signal, no chance.
If you say "we won't change the system catalog just for these two
functions", I can live with that, hoping they slip in following
something's wake.
Regards,
Andreas
On Sun, 8 Aug 2004, Bruce Momjian wrote:
Andreas Pflug wrote:
Bruce Momjian wrote:
Well, there's the logfile rotation issue...
With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.Adding a function will require a system catalog change. If we are
already doing one we might be able to get it in, but I doubt it greatly.We already do more than rotatelogs by specifying a size. That seems
enough to me for now.Basically I think you will need a vote to expand this in 8.1.
Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Sun, 8 Aug 2004, Andreas Pflug wrote:
Marc G. Fournier wrote:
Basically I think you will need a vote to expand this in 8.1.
Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(Summary:
The patch I originally posted (in June) implemented a log rotation, which was
triggered by call to a function, not automatically (subject to a
to-be-written surveillance process), and implemented inside elog.c (more or
less). Tom had many objections, and this emerged to the current
implementation of a subprocess that will do rotation automatically dependent
on size and/or age limits and seems valuable.
'k, for me, as long as it has these two, I'm happy ... that falls in line
with all the ones that I'm used to ...
My postings also included manual triggering of logfile switching,
catching SIGUSR1 (from SendPostmasterSignal) and setting the flag which
otherwise is set by exceeding of configured size/age limit or a
postgresql.conf settings change (SIGHUP triggered).
The only 'server' that I've ever seen this in was aolserver ... and I wish
they'd implement per-size/age ones instead :(
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Import Notes
Reply to msg id not found: 4116A362.8000701@pse-consulting.de
"Marc G. Fournier" <scrappy@postgresql.org> writes:
Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(
The question is whether the new syslogger subprocess has enough features
or not ;-). What it's got is two parameters: switch to a new log file
at least every N minutes, and at least every N kilobytes of log output.
Bruce and I think that's enough. Andreas wants database users to be
able to force it to switch to a new log file on demand.
I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.
regards, tom lane
On Sun, 2004-08-08 at 09:58, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.
Does this mean the feature wont be in 8.0, or that it will be set to 0
page delay by default?
"Scott Marlowe" <smarlowe@qwest.net> writes:
Does this mean the feature wont be in 8.0, or that it will be set to 0
page delay by default?
It will have zero delay by default (pending some more convincing
arguments that is). No one has suggested removing it.
regards, tom lane
Andreas Pflug <pgadmin@pse-consulting.de> writes:
Tom Lane wrote:
I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.
This is a bit contradictionary. pgsql allows any superuser to shoot
himself into his foot (citation: TGL) in many places, e.g. "delete from
pg_class".
There's some significant differences there. In the first place, the
system catalogs are inherently something that is properly manipulated at
the SQL level. In the second place, we have years of experience showing
that it is useful to be able to manipulate them from SQL, see eg
http://developer.postgresql.org/docs/postgres/release-7-4-2.html.
Which is why the occasional proposals about forbidding superusers from
mucking with the catalogs for safety's sake have always been shot down.
The postmaster log isn't an SQL object, so shouldn't really be
manipulated from SQL; and there is zero field experience to suggest that
the time-and-size rotation parameters aren't sufficient for it.
We can always add something later if experience with 8.0 shows that it's
actually needed. But taking out useless features after they've been in
for a release or two is much more painful.
regards, tom lane
Import Notes
Reply to msg id not found: 4116B13D.7070609@pse-consulting.de
Marc G. Fournier wrote:
Basically I think you will need a vote to expand this in 8.1.
Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(
Summary:
The patch I originally posted (in June) implemented a log rotation,
which was triggered by call to a function, not automatically (subject to
a to-be-written surveillance process), and implemented inside elog.c
(more or less). Tom had many objections, and this emerged to the current
implementation of a subprocess that will do rotation automatically
dependent on size and/or age limits and seems valuable.
My postings also included manual triggering of logfile switching,
catching SIGUSR1 (from SendPostmasterSignal) and setting the flag which
otherwise is set by exceeding of configured size/age limit or a
postgresql.conf settings change (SIGHUP triggered).
Signal handling is not a big deal, but can't be coded with a contrib module.
Tom believes nobody needs that, and fears decreased reliability.
Regards,
Andreas
Tom Lane wrote:
"Marc G. Fournier" <scrappy@postgresql.org> writes:
Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(Andreas wants database users to be
able to force it to switch to a new log file on demand.
superuser only, of course.
I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.
This is a bit contradictionary. pgsql allows any superuser to shoot
himself into his foot (citation: TGL) in many places, e.g. "delete from
pg_class". He may delete logfiles while in use, but not trigger the
rotation in an official way, which doesn't seem particularly harmful
(fooling with log_rotation_age and sighup would be a dubious workaround).
Regards,
Andreas
I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
I am not sure how that file is used but it might require us to repackage
beta1.
Patch attached and applied.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/bjm/difftext/plainDownload
Index: src/interfaces/libpq/libpq.rc
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/libpq.rc,v
retrieving revision 1.11
diff -c -c -r1.11 libpq.rc
*** src/interfaces/libpq/libpq.rc 30 Nov 2003 06:09:53 -0000 1.11
--- src/interfaces/libpq/libpq.rc 9 Aug 2004 01:55:11 -0000
***************
*** 1,8 ****
#include <winver.h>
VS_VERSION_INFO VERSIONINFO
! FILEVERSION 7,5,0,0
! PRODUCTVERSION 7,5,0,0
FILEFLAGSMASK 0x3fL
FILEFLAGS 0
FILEOS VOS__WINDOWS32
--- 1,8 ----
#include <winver.h>
VS_VERSION_INFO VERSIONINFO
! FILEVERSION 8,0,0,0
! PRODUCTVERSION 8,0,0,0
FILEFLAGSMASK 0x3fL
FILEFLAGS 0
FILEOS VOS__WINDOWS32
***************
*** 15,27 ****
BEGIN
VALUE "CompanyName", "\0"
VALUE "FileDescription", "PostgreSQL Access Library\0"
! VALUE "FileVersion", "7, 5, 0, 0\0"
VALUE "InternalName", "libpq\0"
VALUE "LegalCopyright", "Copyright (C) 2004\0"
VALUE "LegalTrademarks", "\0"
VALUE "OriginalFilename", "libpq.dll\0"
VALUE "ProductName", "PostgreSQL\0"
! VALUE "ProductVersion", "7, 5, 0, 0\0"
END
END
BLOCK "VarFileInfo"
--- 15,27 ----
BEGIN
VALUE "CompanyName", "\0"
VALUE "FileDescription", "PostgreSQL Access Library\0"
! VALUE "FileVersion", "8, 0, 0, 0\0"
VALUE "InternalName", "libpq\0"
VALUE "LegalCopyright", "Copyright (C) 2004\0"
VALUE "LegalTrademarks", "\0"
VALUE "OriginalFilename", "libpq.dll\0"
VALUE "ProductName", "PostgreSQL\0"
! VALUE "ProductVersion", "8, 0, 0, 0\0"
END
END
BLOCK "VarFileInfo"
re-tag'd and building new bundle now to include the change *just in case*
On Sun, 8 Aug 2004, Bruce Momjian wrote:
I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
I am not sure how that file is used but it might require us to repackage
beta1.Patch attached and applied.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
Drat. I grepped for '7.5' and '705', but not for '7, 5' :-(
I am not sure how that file is used but it might require us to repackage
beta1.
Nah, not worth the trouble. Good thing you noticed it before final though.
regards, tom lane
Drat. I grepped for '7.5' and '705', but not for '7, 5' :-(
I am not sure how that file is used but it might require us to repackage
beta1.Nah, not worth the trouble. Good thing you noticed it before final though.
Maybe you guys should keep a list of all places that need updating and
all jobs that need to be done before a release, so we don't forget
anything :)
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Maybe you guys should keep a list of all places that need updating and
all jobs that need to be done before a release, so we don't forget
anything :)
src/tools/RELEASE_CHANGES ... but it didn't occur to me to consult that
while relabeling 7.5 to 8.0 :-(
regards, tom lane
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.
Won't try to convince more people. I was about to disable it when Bruces
commit message flew by.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.Won't try to convince more people. I was about to disable it when Bruces
commit message flew by.
Jan, I hate to back out someone else's patches. I should have waited longer.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 8/9/2004 3:46 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.Won't try to convince more people. I was about to disable it when Bruces
commit message flew by.Jan, I hate to back out someone else's patches. I should have waited longer.
You know that it's fine with me. Actually it's my turn to apologize in
this case because I activated vacuum_cost_delay under false assumptions
and lacking discussion.
I was a bit slow in backing it out because my VM crashed once following
several suspends, and I had to get my notebook into a friends WLan. So I
was happy to see you did it already.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Regression tests on PostgreSQL 8 Beta are successful.
[pgsql8@lora01 regress]$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon)
[pgsql8@lora01 regress]$ uname -a
Linux lora01 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686
i686 i386 GNU/Linux
Bruce Momjian wrote:
pgman wrote:
Marc G. Fournier wrote:
'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?Speak now, or forever hold your piece :)
The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.OK, I think Jan agreed not to have vacuum delay enabled by default so I
backed out his patch to it is now disabled.Patch attached and applied.
I think this means we are ready for beta1.
------------------------------------------------------------------------
Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.227 retrieving revision 1.228 diff -c -c -r1.227 -r1.228 *** src/backend/utils/misc/guc.c 6 Aug 2004 04:15:09 -0000 1.227 --- src/backend/utils/misc/guc.c 7 Aug 2004 03:08:44 -0000 1.228 *************** *** 1046,1052 **** NULL }, &VacuumCostDelay, ! 0, 0, 1000, NULL, NULL },{ --- 1046,1052 ---- NULL }, &VacuumCostDelay, ! 50, 0, 1000, NULL, NULL },{ Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.121 retrieving revision 1.122 diff -c -c -r1.121 -r1.122 *** src/backend/utils/misc/postgresql.conf.sample 7 Aug 2004 01:04:50 -0000 1.121 --- src/backend/utils/misc/postgresql.conf.sample 7 Aug 2004 03:08:49 -0000 1.122 *************** *** 74,80 **** #vacuum_cost_page_miss = 10 # 0-10000 credits #vacuum_cost_page_dirty = 20 # 0-10000 credits #vacuum_cost_limit = 200 # 0-10000 credits ! #vacuum_cost_delay = 0 # 0-1000 milliseconds# - Background writer - #bgwriter_delay = 200 # 10-5000 milliseconds --- 74,80 ---- #vacuum_cost_page_miss = 10 # 0-10000 credits #vacuum_cost_page_dirty = 20 # 0-10000 credits #vacuum_cost_limit = 200 # 0-10000 credits ! #vacuum_cost_delay = 50 # 0-1000 milliseconds# - Background writer -
#bgwriter_delay = 200 # 10-5000 milliseconds------------------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
--
Jonah H. Harris, UNIX Administrator | phone: 505.224.4814
Albuquerque TVI | fax: 505.224.3014
525 Buena Vista SE | jharris@tvi.edu
Albuquerque, New Mexico 87106 | http://w3.tvi.edu/~jharris/
"All great truths begin as blasphemies."
-- George Bernard Shaw