Looks reasonable to me. All the patch does is make sure that the result
set is valid. Probably a check I should have done from the beginning,
or pg _autovacuum should be locking tables to make sure they aren't
dropped, but that sounds too intrusive, this is probably better.
Matt
daveg
.
Please apply this patch to both HEAD and 7.4.
Thanks much,
Matthew O'Connor
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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. I am resubmitting them
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
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_vacuum_count = 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 = atol(PQgetvalue(res, row, PQfnumber(res, relpages
went ahead
added a check to any section that did anything with the result of
send_query, so if this was an issue, it should be fixed now. BTW, this
might have been the cause of the temp table related crash, but that is
just a guess.
Matthew O'Connor
*** ./pg_autovacuum.c.orig 2004-05-22 02:56
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. Attached is a patch
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 a postmaster child,
then it is run
executable for the time
being. Time permitting, I will make the postmaster launch and kill this
app as needed, or fold it into the postmaster more like the stats
collector. But for now this gets it out of contrib.
Matthew O'Connor
*** ./contrib/Makefile.orig 2004-05-29 04:22:36.628996015 -0400
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_autovacuum Makefile which will be in src/bin
would make it quite inappropriate for autovacuum to live in
src/bin.
Ok.
BTW, Matthew, I am currently working on promoting the bgwriter into a
more full-fledged postmaster child. If you can wait a day or so you
should have a decent model to work from. I'll try to commit as soon
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 wait a few days? Especially given
pg_autovacuum.h into src/include/postmaster and apply the patch.
Matthew O'Connor
ps, I am hoping to get this work in before feature freeze.
*** ./src/backend/bootstrap/bootstrap.c.orig 2004-06-05 15:32:02.0 -0400
--- ./src/backend/bootstrap/bootstrap.c 2004-06-05 15:33:13.0 -0400
patch. I think backend integration will eliminate the
need for your autovacuum service patch no?
Matthew
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere
of libpq is not a bug, it's a feature.
Thoughts?
Matthew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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. O'Connor wrote:
FYI, I am out of town from
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. :-)
:-)
/ for the new pg_autovacuum system
table.
Please apply to CVS or tell me what I need to change to get it applied.
Matthew
/*-
*
* pg_autovacuum.h
* definition of the system autovacuum relation (pg_autovacuum)
*
* NOTE
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 considerably. Should I submit the patch in a different
way?
Thanks,
Matthew
I am having problem applying this. I don't think we can just move
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 considerably. Should I submit the patch in a
different
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 a problem
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 Matthew
on it...
Anyway, I'm very willing to do as much of the lifting as I can.
Matthew
---(end of broadcast)---
TIP 8: explain analyze is your friend
by lots of users.
Thanks again for the code review, let me know what I should do, and I'll
get on it ASAP.
Matthew
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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
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 me know if
I'm heading
better ideas?
Please review and if deemed accecptable, please apply to CVS HEAD.
Thanks,
Matthew O'Connor
*** ./pg_autovacuum.c.orig 2004-10-26 00:00:00.0 -0400
--- ./pg_autovacuum.c 2004-10-26 01:15:40.0 -0400
***
*** 973,978
--- 973,1054
return res
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
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 also affects
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 not right ... are there any
until it's told to exit.
Matthew
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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 attached
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,
commands respect the GUC vacuum delay settings?
Should we be able to set per table vacuum delay settings?
This patch doesn't have the maintenance window that was discussed a
while ago. Can that be added after July 1?
Thanks Alvaro for doing the integration work
Matthew O'Connor
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
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
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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're
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
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
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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 counter. Somehow I
Tom Lane wrote:
+ Additionally to the base threshold values and scale factors, there are
+ two parameters that can be set for each table in structnamepg_autovacuum/structname:
Additionally to is not good style ... maybe Besides?
I think In addition to was what Alvaro meant,
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
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
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
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
46 matches
Mail list logo
