"Matthew T. O'Connor" writes:
> 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.
>>
> 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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
>> pg_autovacuum should only contain user-settable parameters ---
> Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
> change autovac parameters?
I think we'll want them
On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Here is a second attempt at autovacuum integration.
>
> A few comments:
Excellent, thanks. I'll be working on fixing all these.
> * I strongly disagree with keeping updatable state in a ca
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here is a second attempt at autovacuum integration.
A few comments:
* I strongly disagree with keeping updatable state in a catalog. In the
first place, that will cause autovac itself to create vacuumable trash.
In the second place, that means you can
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
Matthew T. O'Connor wrote:
> I think so. Something like: Improve autovacuum xid wraparound detection
> by moving to a pertable solution rather than per database.
Thanks, added.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610)
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
TODO item?
---
Alvaro Herrera wrote:
> On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
> > "Matthew T. O'Connor" writes:
> > > Tom Lane wrote:
> > >> No, you're wrong. VACUUMing of individual tables is perfectly
On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> No, you're wrong. VACUUMing of individual tables is perfectly good
> >> enough as far as XID wrap protection goes, it's just that we chose to
> >> track whether it had been done at t
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> No, you're wrong. VACUUMing of individual tables is perfectly good
>> enough as far as XID wrap protection goes, it's just that we chose to
>> track whether it had been done at the database level. If we tracked it
>> in, say, a new pg_class colu
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're wrong. VACUUMing o
"Matthew T. O'Connor" writes:
>>> Hmm. Yes, this patch doesn't handle Xid wraparound. This should be
>>> easy to add though. Anyway, I was thinking that we could add a "last
>>> vacuum Xid" to pg_autovacuum, and handle Xid wraparound for each table
>>> separately -- this means you don't have to
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. Ok, so I'm not wr
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
Matthew, your reply was exactly the type of reply I would have made in
your situation. Your arguments are clear and indisputable.
Due to the many large patches the we had to process during this release,
we serialized their review. However, I made promises to developers that
their patches would
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 06 August 2004 00:42
> To: Matthew T. O'Connor
> Cc: PostgreSQL Patches
> Subject: Re: [PATCHES] Autovacuum Integration Patch Take 5
>
> "M
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
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 committab
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> BTW, I know people are eager for 8.0, but given that our release cycle
> is so long, and that by everyones estimates we are at least 3 months
> away from a release, what is the hurry for beta?
If I thought we were just a day or two away from ha
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 in
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
"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 in the right d
Patch withdrawn by author. Will resubmit.
---
Matthew T. O'Connor wrote:
> 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 lates
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
>>
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
> way?
I don't see any modifications to pg_autovacuum.[ch] in
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
>
I am having problem applying this. I don't think we can just move
pg_autovacuum.[ch] right into the backend code. There are issues with
include files and there is no definition for autovacuum_vacuum_base and
other variables, and there is no AutoVacMain(). I can try guessing on
those but I think
29 matches
Mail list logo
