-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jan 16, 2007 at 11:23:36AM -0300, Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
>
[...]
> Now I'm starting to wonder what will happen between 23:59:59 of day X
> and 00:00:00 of day (X+1) ... Maybe what we should do is not specify
> an e
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
This still seems ambiguous to me, how would I handle a maintenance
window of Weekends from Friday at 8PM though Monday morning at 6AM? My
guess from what said is:
mon dom dow starttime endtime
null null6 20:00 null
null null
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With that taken care of, do I dare propose enabling autovacuum by
> default, so that further changes will be picked up quickly by the
> buildfarm?
Sure, let's try it and see what else breaks ;-)
regards, tom lane
--
On Monday 15 January 2007 15:13, Darcy Buskermolen wrote:
> On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
> > > While we are talking autovacuum improvements, I'd like to also see some
> > > better logging, something that is akin to the important information of
> > > vacuum verbose being l
Matthew T. O'Connor wrote:
> This still seems ambiguous to me, how would I handle a maintenance
> window of Weekends from Friday at 8PM though Monday morning at 6AM? My
> guess from what said is:
> mon dom dow starttime endtime
> null null6 20:00 null
> null null1 null
Tom Lane wrote:
> Actually the reason it's not enabled by default today has nothing to do
> with either of those; it's
>
> 3. Unexpected side effects on foreground processes, such as surprising
> failures of DROP DATABASE commands. (See archives for details.)
>
> Until (3) is addressed I don't
On Monday 15 January 2007 15:23, Joshua D. Drake wrote:
> Darcy Buskermolen wrote:
> > On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
> >>> While we are talking autovacuum improvements, I'd like to also see some
> >>> better logging, something that is akin to the important information of
>
Darcy Buskermolen wrote:
> On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
>>> While we are talking autovacuum improvements, I'd like to also see some
>>> better logging, something that is akin to the important information of
>>> vacuum verbose being logged to a table or baring that the err
On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
> > While we are talking autovacuum improvements, I'd like to also see some
> > better logging, something that is akin to the important information of
> > vacuum verbose being logged to a table or baring that the error_log. I'd
> > like to be
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Here it is.
>
> I'd drop the InitProcess API change, which touches many more places than
> you really need, and just have InitProcess check IsAutoVacuumProcess(),
> which should be valid by the time control gets to it. This is more
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Note that currently there's no way for a backend to know whether another
> backend is autovacuum or not. I thought about adding a flag to PGPROC,
> but eventually considered it ugly,
No, that was exactly the way I thought we'd do it. One thing to note
Tom Lane wrote:
> Also see Peter's nearby suggestion that we ought to wait instead of fail
> for *all* cases of somebody attached to the database. This would adapt
> readily enough to that.
>
> I was complaining elsewhere that I didn't want to use a sleep loop
> for fixing the fsync-synchronizat
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm cooking a patch for this which seems pretty reasonable, but I'm
> having a problem: what mechanism do we have for waiting until a process
> exits?
None, and I think you probably don't want to sit on the database lock
while waiting, either. I was en
Tom Lane wrote:
> The DROP is at risk, but CREATE is also at risk because autovac feels
> free to connect to template0. (One of the reasons we invented template0
> was to prevent CREATE DATABASE failures due to someone-else-connected,
> but autovac has broken that idea.)
ALTER DATABASE RENAME al
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
pg_av_igroupmembers
groupid oid
month int
dom int
dow int
starttime timetz
endtime timetz
This seems to assume that the start and end time for an interval will be
on th
Alvaro Herrera wrote:
> Hmm, I can see having DROP DATABASE just stopping the autovacuum
> (since the work will be thrown away),
For that same reason DROP DATABASE could just cut all connections to the
database. Or at least queue up and wait until the session is over.
(The latter would corresp
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Possibly we could handle these by extending create/drop db to check
>> whether a process-connected-to-the-target-db is an autovac, and if so
>> send it a SIGINT and wait for the process to terminate, instead of
>> failing.
> Hmm, I ca
Tom Lane wrote:
> >> * contrib tests fail in their repeated drop/create database operations
> >> because autovac is connected to that database. (pl tests presumably
> >> have same issue.)
>
> The DROP is at risk, but CREATE is also at risk because autovac feels
> free to connect to template0. (
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >I've been thinking how to improve autovacuum so that we can convince
> >more people that it can be enabled by default.
>
> I would like to see it enabled by default too, however the reason it
> isn't already enabled by default is that it ca
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, right. The mentioned problems are:
>> * manual ANALYZE issued by regression tests fails because autovac is
>> analyzing the same table concurrently.
This problem might have gone away since then --- I think we are now
taking a lock to ensure only
Tom Lane wrote:
> Actually the reason it's not enabled by default today has nothing to do
> with either of those; it's
>
> 3. Unexpected side effects on foreground processes, such as surprising
> failures of DROP DATABASE commands. (See archives for details.)
The referred to thread starts here:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've been thinnking how to improve autovacuum so that we can convince
> more people that it can be enabled by default. Here are my thoughts.
> There are two areas of improvements:
> 1. scheduling, and
> 2. process handling, i.e., how to have multiple v
First, thanks for working on this. I hope to be helpful with the design
discussion and possibly some coding if I can find the time.
My initial reaction to this proposal is that it seems overly complex,
however I don't see a more elegant solution. I'm a bit concerned that
most users won't fig
> While we are talking autovacuum improvements, I'd like to also see some
> better
> logging, something that is akin to the important information of vacuum
> verbose being logged to a table or baring that the error_log. I'd like to be
> able to see what was done, and how long it took to do fo
On Sunday 14 January 2007 05:18, Alvaro Herrera wrote:
> I've been thinnking how to improve autovacuum so that we can convince
> more people that it can be enabled by default. Here are my thoughts.
> There are two areas of improvements:
>
> 1. scheduling, and
> 2. process handling, i.e., how to ha
25 matches
Mail list logo
