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 wro
t in by
mistake.
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
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,
analyzes on during startup.
Second, there was a debug print statement left in that was printing
relisshared.
The attached patch fixes both issues, and should be applied to both 7.4
and HEAD.
Thanks,
Matthew O'Connor
*** pg_autovacuum.c.orig 2003-12-07 15:25:08.0 -0500
--- pg_autovac
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.
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
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 =
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->
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
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
but I 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-0
will be in src/bin/pg_autovacuum/Makefile
once the pg_autovacuum directory is moved.
If there is anything else I can to to facilitate this move, let me know
and I'll do it.
Matthew O'Connor
---(end of broadcast)---
TIP 1: subscribe and u
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
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
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
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 at stats maintained in the FSM. These
> attributes 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
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
ster,
move 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.
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
it another 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 YourEmail
OR, " Please fix the problems and try
> > again.");
>
> > If you use the ereport() call instead of elog, you can set the second
> > one as a HINT. Since it's really the same error, I don't think you want
> > multiple errors logged...
>
> Even m
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.
etc...)
IMHO, the use 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
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.
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.
telog/ 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_autovac
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
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
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
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:
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:
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:
+ 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.
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
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
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
ing beta ...
>
> I see. :-(
>
> I know Matthew just got back from being away so perhaps he has time to
> address some of these. I say we see if he can and move on the other
> open items and see where this is when they are complete.
Yes I'm here, and I'm quite willing t
#x27;m just pushing to get autovac into 7.5, I'm
sure there are lots of people on this list who could have done a better
job, but nobody working 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
...
I don't know either as it's not my decision to make :-) As I said
though, I'm willing to make all the fixes I mentioned above if you tell
me there is a decent change it will get applied 7.5.
BTW, despite the simplicity of autovac, lots of people are using the
contrib version a
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
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:
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
t
Any 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
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
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
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
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
o it's job 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" 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:
-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
hould be integrated, so these
issues can be tackled by interested parties.
Couple of other thoughts:
Do the vacuum 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
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:
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.
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
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'
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
riate here. (8.1)
* Improve autovacuum threshold defaults (8.1)
Anyone have anything to add to the list?
Matthew
Bruce Momjian wrote:
TODO item?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an approp
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
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:
"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
62 matches
Mail list logo
