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
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:
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
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
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:
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:
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:
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
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
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
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
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,
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:
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
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
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
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
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:
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
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 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 might
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. The
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
this applied. Also, it uses the gcc-ism
__attribute__ that isn't portable to other compilers.
---
Matthew T. O'Connor wrote:
Ok, here is a new patch for to integrate pg_autovacuum into the backend.
This patch adds
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
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
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. :-)
:-)
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
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
! /* pg_autovacuum.c
* All the code for the pg_autovacuum program
* (c) 2003 Matthew T. O'Connor
* Revisions by Christopher B. Browne, Liberty RMS
*/
! #include pg_autovacuum.h
- FILE *LOGOUTPUT;
char logbuffer[4096];
! static void
! log_entry(const char *logentry)
{
! time_t curtime
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
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
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
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 being
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
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
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
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
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
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
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
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
45 matches
Mail list logo
