Thread: 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
-------
* Win32o binary version stampso signal safe socket handlero query cancel in psql (?) o Report correct errno codes
fromnative Windows system callso Shorten timezone for %t log_line_prefixo start pg_autovacuum easilyo fix pitr file
copysyntax
* 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,
Pennsylvania19073
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
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. -- 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 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
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, Pennsylvania19073
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 <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, Pennsylvania19073
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, Pennsylvania19073
"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
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
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, Pennsylvania19073
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
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
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
"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?
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
"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
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 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, Pennsylvania19073
On 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