Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
But this is misleading (started postmaster with good value, then edited
postgresql.conf and entered "-2"):
17903 LOG: received SIGHUP, reloading configuration files
17903 LOG: -2 is outside the valid range for pa
Alvaro Herrera wrote:
Alvaro Herrera wrote:
New version of the patch attached.
I'll probably apply this tomorrow morning unless there are objections.
An important difference from the previous patch is that
DatabaseHasActiveBackends (now renamed to
DatabaseCancelAutovacuumActivity) cycles throug
Alvaro Herrera wrote:
My vision is a little more complex than that. You define group of
tables, and separately you define time intervals. For each combination
of group and interval you can configure certain parameters, like a
multiplier for the autovacuum thresholds and factors; and also the
"e
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
In the case of a heavily update workload, the default naptime (60 seconds)
is too long to keep the number of dead tuples low. With my patch, the naptime
will be adjusted around 3 seconds at the case of pgbench (scale=10, 80 tps)
with default other a
Tom Lane wrote:
daveg <[EMAIL PROTECTED]> writes:
Below is a patch for this that should apply against any 8.0.x. The change
verifies that the catalog query returned some rows before accessing the row
data.
Surely this is completely broken? AFAICT you are testing the result
from a VACU
Tom Lane wrote:
+ Additionally to the base threshold values and scale factors, there are
+ two parameters that can be set for each table in pg_autovacuum:
"Additionally to" is not good style ... maybe "Besides"?
I think "In addition to" was what Alvaro meant, which works.
Alvaro Herrera wrote:
Two comments still apply:
- I haven't done anything yet w.r.t. the custom vacuum_delay nor sleep
scale factor.
I don't think we need the sleep scaling factor. Before we had vacuum
delay settings, it might have been useful as a means of throttling down
the impact of
Tom Lane wrote:
"Matthew T. O'Connor" writes:
I don't know either, but this brings up another question. Stats
wraparound.
We'll all be safely dead, for one thing ;-)
At one update per nanosecond, it'd take approximately 300 years to wrap
a 64-bit co
Alvaro Herrera wrote:
On Sun, Jul 24, 2005 at 02:33:38PM -0400, Tom Lane wrote:
Hmm, I wonder whether the minimum shouldn't be 10. Or even 60.
It's ok with me. What do other people think?
Effectiely, this is going to be the minimum amount of "down time" for
autovacuum between
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
change autovac parameters?
I think we'll want them eventually, but I don't mind if 8.1 ships
without 'em.
It might be good to ship 8.1 without them
While we are at it (assuming the autovacuum patch gets included in 8.1)
we have a few autovacuum related todo items.
These are the ones I can think of right now:
* XID Wraparound improvement, moving to per-table vacuuming rather than
per database. (8.2)
* Alter table commands to set per table
I think so. Something like: Improve autovacuum xid wraparound detection
by moving to a pertable solution rather than per database.
Matt
Bruce Momjian wrote:
TODO item?
---(end of broadcast)---
TIP 2: you can get off all lists at once wi
Tom Lane wrote:
"Matthew T. O'Connor" writes:
The current implementation of XID wraparound requires that the vacuum
command be run against the entire database, you can not run it on a per
table basis and have it work. At least that is my understanding,
No, you'
XID wraparound: The patch as submitted doesn't handle XID wraparound
issues. The old contrib autovacuum would do an XID wraparound check as
it's 1st operation upon connecting to a database. If XID wraparound was
looks like it's going to be a problem soon, then the whole database
would be vac
Alvaro Herrera wrote:
On Thu, Jun 30, 2005 at 12:03:12AM -0400, Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
Sorry, forgot to mention:
- There are no docs
I can help here as long as I don't have to have the docs done before July 1.
You don't.
Alvaro Herrera wrote:
Hackers,
Here is a first cut at autovacuum integration. Please have a look at
it. Note that this patch automatically creates three new files:
Couple more things that I didn't think about while we were talking about
this the other day.
XID wraparound: The patch a
Alvaro Herrera wrote:
There are several things that are painfully evident with this thing on:
- TRUNCATE does not update stats. It should send a stat message to
which we can react.
How important is this really? The stats from before the truncate might
be ok, especially since they might
Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
I would argue actually that this switch is a horrible idea and we
must take it out entirely. The method Ian proposes for hiding the
password after reading it is certainly not portable in the slightest,
a
Tom Lane wrote:
"Matthew T. O'Connor" writes:
In the windows service world, is there any reason pg_autovacuum should
ever give up?
I was a bit worried about the scenario in which J Random Luser tries to
start the server twice and ends up with two autovacuum daemons attac
Dave Page wrote:
When starting as a service at boot time on Windows, pg_autovacuum may
fail to start because the PostgreSQL service is still starting up. This
patch causes the service to attempt a second connection 30 seconds after
the initial connection failure before giving up entirely.
In the
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
+ if(operation == VACUUM_ANALYZE)
+ update_table_thresholds(dbi, tbl, VACUUM_ANALYZE);
+ else if(operation == VACUUM_ANALYZE)
+ update_table_thresholds(dbi, tbl, ANALYZE_ONLY);
Surely that's n
Ok, here is an updated version of the patch I submitted last night.
This patch now sets the appropriate vacuum cost variables for both
vacuum commands and analyze commands. In addition I have added the new
vacuum cost options to the win32 InstallService function.
Please give it another look
Michael Paesold wrote:
Matthew T. O'Connor wrote:
Two questions:
1) It is my understanding that these new GUC vars only effect vacuum.
That is they do NOT have any effect on an analyze command right? (I ask
since I'm only setting the vars before I issue a vacuum command)
No, vacuum al
Dave Page wrote:
Hi Matthew,
It doesn't look like you modified the Win32 service installation code to
write these options to the registry when installing the service (see
szCommand in InstallService()).
Oops Can you tell I didn't write that part of the code ;-) I'll
take a look at this tonig
Hello, as per some discussion on the lists a few days ago, I am
submitting this patch against the CVS version of pg_autovacuum.
This patch adds 5 new command line options to pg_autovacuum that
directly correspond to the 5 new vacuum cost GUC variables in 8.0. I
have done some simple testing
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
Well I didn't get out of the office as early as I had hoped, and I have
stayed up longer than I had planned, but I have a patch that addresses
many of the issues raised by Tom. Please take a look at let
Tom Lane wrote:
You're headed in the right direction, but I'm afraid we're running out
of time. The core committee has chewed this over and agreed that we
can't postpone beta for the amount of time we think it will take to make
this patch committable. So we're going to hold it over for the 8.1
re
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I agree. The thought had crossed my mind that autovac should shut down
first, but I'm really not sure how to make that happen.
You have to issue the kill() when the postmaster first receives the
shutdown s
On Mon, 2004-08-02 at 19:26, Tom Lane wrote:
> I looked over this patch (sorry for the delay), and found a number of
> problems.
Thanks for the feedback, hopefully we can still get something in place
for 7.5.
> Bigger problems:
>
> * I don't think you've thought through system shutdown at all.
On Mon, 2004-08-02 at 21:53, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As far as libpq, can't pg_autovacuum dynamically load libpq like dblink
> > does?
>
> Hmm, make the bulk of the autovac daemon be a shlib that is dynamically
> linked by just that subprocess? Yeah, that m
On Mon, 2004-08-02 at 21:36, Bruce Momjian wrote:
> Tom Lane wrote:
> > I'm not sure what we do now. I can't apply this in its current state,
> > and I do not have time to fix it. I don't really want to push it in
> > and assume we can fix the problems during beta ...
>
> I see. :-(
>
> I know
Peter Eisentraut wrote:
Matthew T. O'Connor wrote:
As before, to apply this patch:
1) Move pg_autovacuum.c and .h get from contrib to
src/backend/postmaster and src/include/postmaster respectively.
Trivial comment: maybe we can drop the pg_ prefix on the file names.
Ok, that's not
Ack! I sent the wrong patch... Sorry I will resend it tonight.
> Matthew T. O'Connor wrote:
>> Sorry, perhaps my initial instructions weren't clear.
>>
>> You have to move the pg_autovacuum.[ch] files then apply the patch. The
>> patch alters them consider
more complete
> instructions to get this applied. Also, it uses the gcc-ism
> __attribute__ that isn't portable to other compilers.
>
> -----------
>
> Matthew T. O'Connor wrote:
>> Ok, here
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 fal
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.
enabled is read from GUC before the stats variables,
and there is no way to force the order in which they are read. Am I
missing something?
Matthew
> Matthew, were are we on this patch?
>
> -----------
>
> Matthew 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
is set
to true. Is there someway to force the order in which variables are
read from GUC?
Thanks,
Matthew
On Tue, 2004-06-29 at 10:44, Matthew T. O'Connor wrote:
> I have make the changes suggested after I posted my last patch, I have
> also make several additional improvements.
On Wed, 2004-06-16 at 10:01, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > I also noticed:
> > ! elog(ERROR, "pg_autovacuum: GUC variable stats_row_level
> > must be enabled.");
> > ! elog(ERROR, " Please fix the problems and try
> > again.");
>
> >
Dave Page wrote:
Personally I don't care as I use XP/2K3 anyway, but having been told my
autovacuum service code needed to support NT4
I have been working on integrating pg_autovacuum into the backend, and I
have it working, I'm just trying to clean up some lose ends before I
submit another p
Euler Taveira de Oliveira wrote:
Hi Matthew,
Cool. Last week I just take a look at it and have some ideas.
Such as?
I am planning on doing much more in the next few days including:
* creating pg_autovacuum related guc variables
* create a new system table for pg_autovacuum settings
* alter pg_class
vacuum.c.orig 2004-06-07 00:39:57.0 -0400
--- ./src/backend/postmaster/pg_autovacuum.c 2004-06-07 00:35:51.00000 -0400
***
*** 1,65
! /* pg_autovacuum.c
* All the code for the pg_autovacuum program
* (c) 2003 Matthew T. O'Connor
* Revisions by Christopher B. Browne, Liberty RMS
On Sat, 2004-05-29 at 15:02, Marc G. Fournier wrote:
> On Sat, 29 May 2004, Matthew T. O'Connor wrote:
> > I can wait, but I am really trying not to miss the feature freeze which
> > AFAIK, is still happening in a few days. Is that changing? Will I have
> > time if I w
On Sat, 2004-05-29 at 11:04, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It is supposed to be linked into the postmaster and forked from there.
>
> In the current state of pg_autovacuum it wouldn't matter a lot, but
> I am assuming that we will soon migrate it to depend on b
On Sat, 2004-05-29 at 02:15, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > As outlined in my email, step 1 is to move pg_autovacuum from contrib to
> > src/bin. Attached is a patch that modifies src/bin/Makefile and the
> > pg_au
Ok, based on feedback from Tom and Peter, here is another stab at moving
pg_autovacuum from: contrib/pg_autovacuum to: src/backend/postmaster
In summary pg_autovacuum.c has to be moved to src/backend/postmaster,
pg_autovacuum.h moves to src/include. The apply the attached patch
which makes the re
On Sat, 2004-05-29 at 02:45, Peter Eisentraut wrote:
> Matthew T. O'Connor wrote:
> > The only reason I put it in src/bin is because I thought people
> > wanted pg_autovacuum to still be a runable stand alone app.
>
> I see no reason for that. If it's integrated as
On Sat, 2004-05-29 at 01:31, Matthew T. O'Connor wrote:
> Having no response from my email to hackers yesterday, I will assume
> (hope) that no news is good news and proceed onwards.
>
> As outlined in my email, step 1 is to move pg_autovacuum from contrib to
> src/bin. Atta
Having no response from my email to hackers yesterday, I will assume
(hope) that no news is good news and proceed onwards.
As outlined in my email, step 1 is to move pg_autovacuum from contrib to
src/bin. Attached is a patch that modifies src/bin/Makefile and the
pg_autovacuum Makefile which will
This weekend I am trying to fix up all known the pg_autovacuum issues
that should be resolved for 7.4.3. I am aware of only two issues: temp
table issues, and unchecked send_query() calls, if I am forgetting
something, please let me know.
1) temp table issue:
I was not able to reproduce the cr
Andrew Dunstan wrote:
***
*** 129,135
-v 1000
-V 2
-a 500 (half of -v if not specified)
! -A 1 (half of -v if not specified)
-s 300 (5 minutes)
-S 2
--- 129,135
-v 1000
-V 2
-a 500 (half of -v if not specified)
! -A 1 (half of -V if not specified)
-s 300
debugging output to be more consistent.
Please apply to both HEAD and the 7.4 branch.
Matthew T. O'Connor
*** ./pg_autovacuum.c.orig 2004-03-16 23:30:18.372862648 -0500
--- ./pg_autovacuum.c 2004-03-16 23:17:41.187613298 -0500
***
*** 359,377
void
print_table_info(tbl
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
! new_tbl->relid = atol(PQgetvalue(res, row, PQfnumber(res,
"oid")));
! new_tbl->reltuples = atof(PQgetvalue(res, row, PQfnumber(res,
"reltuples")));
! new_tbl->
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
! new_tbl->relid = atol(PQgetvalue(res, row, PQfnumber(res, "oid")));
! new_tbl->reltuples = atof(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
! new_tbl->relpages =
and make sure its valid.
Matthew T. O'Connor
*** ./pg_autovacuum.c.orig 2004-02-28 18:08:10.0 -0500
--- ./pg_autovacuum.c 2004-03-04 02:16:37.607509231 -0500
***
*** 117,125
atol(PQgetvalue(res, row, PQfnumber(res, "n_tup_upd";
new_tbl->curr_vacu
On the performance list, Gaetano Mendola noticed that pg_autovacuum
doesn't perform an fflush after the last log_entry call before sleeping.
This makes tail -f very annoying to watch.
Attached is a patch to add that one line.
Matthew
*** pg_autovacuum.c.orig 2003-12-08 00:30:08.0 -050
Ok, one more pg_autovacuum patch (Thanks to Tom for fixing the long long
overflow problem).
This patch addresses two minor issues (the last two pg_autovacuum bugs I
know of):
First the CountAtLastAnalyze varable was initially being set incorrectly
causing pg_autovacuum to perform unneeded anal
One more time... The last patch didn't have the unitialized variables
stuff in it. Please disregard the previous patch and apply this one.
On Sat, 2003-11-29 at 00:34, Matthew T. O'Connor wrote:
> ARRRGGHH ok, with patch this time...
>
> On Sat, 2003-11-29 at 00:17,
ARRRGGHH ok, with patch this time...
On Sat, 2003-11-29 at 00:17, Matthew T. O'Connor wrote:
> Hello,
>
> I noticed that there have been a few patched submitted for pg_autovacuum
> that have not been applied, so I applied them locally and tested them on
> my Fedora box
Hello,
I noticed that there have been a few patched submitted for pg_autovacuum
that have not been applied, so I applied them locally and tested them on
my Fedora box. I am resubmitting them as one single patch.
Included in the attached patch:
Brian Hurt's patch that fixed the truncate bug by
61 matches
Mail list logo
