Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Hannu Krosing) wrote:
Christopher Browne kirjutas E, 03.11.2003 kell 02:15:
Well, actually, the case where it _would_ be troublesome would be
where there was a combination of huge tables needing vacuuming and
smaller ones
Ang Chin Han wrote:
Christopher Browne wrote:
Centuries ago, Nostradamus foresaw when Stephen
[EMAIL PROTECTED] would write:
As it turns out. With vacuum_page_delay = 0, VACUUM took 1m20s (80s)
to complete, with vacuum_page_delay = 1 and vacuum_page_delay = 10,
both VACUUMs completed in 18m3s
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we will see wildforms with one or the other feature applied.
I'd believe that for
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later suggestions (sleep 10 ms every N blocks, instead of N ms every
On Tue, 2003-11-11 at 09:42, Shridhar Daithankar wrote:
Peter Eisentraut wrote:
Shridhar Daithankar writes:
I think so too.. I have been planning to do that for dbmail and egroupware
but haven't got around it..
When I said I've been doing a bit of that, I meant the developers of
On Wed, 2003-11-12 at 23:44, Lamar Owen wrote:
My hands are somewhat tied at the present to only supporting what I actively
run. That is currently RHL 8.0 and Fedora Core 1. (not 1.0, incidentally;
there is no minor version).
Have you tried mach?
Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already
Christopher Kings-Lynne wrote:
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't
mean it's
useful.
I don't call porting Postgres to run
Shridhar Daithankar wrote:
Josh Berkus wrote:
Shridhar,
However I do not agree with this logic entirely. It pegs the next
vacuum
w.r.t current table size which is not always a good thing.
Ok, what do you recommend? The point of two separate variables allows
you to specify if you want
Shridhar Daithankar wrote:
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I am still wary of inverting vacuum analyze frequency. You think it is
better to set inverted default rather than documenting it?
I think inverting the vacuum
Tom Lane wrote:
Chester Kustarz [EMAIL PROTECTED] writes:
vacuum is to reclaim dead tuples. this means it depends on update and
delete. analyze depends on data values/distribution. this means it depends on
insert, update, and delete. thus the dependencies are slightly different
between the 2
Josh Berkus wrote:
Matthew,
For small tables, you don't need to vacuum too often. In the testing I
did a small table ~100 rows, didn't really show significant performance
degredation until it had close to 1000 updates.
This is accounted for by using the threshold value. That way
Robert Treat wrote:
Just thinking out loud here, so disregard if you think its chaff but...
if we had a system table pg_avd_defaults
[snip]
As long as pg_autovacuum remains a contrib module, I don't think any
changes to the system catelogs will be make. If pg_autovacuum is
deemed ready to
Josh Berkus wrote:
Matthew,
True, but I think it would be one hour once, rather than 30 minutes 4
times.
Well, generally it would be about 6-8 times at 2-4 minutes each.
Are you saying that you can vacuum a 1 million row table in 2-4
minutes? While a vacuum of the same table with an
Josh Berkus wrote:
Matthew,
But we could create a config file that would store stuff in a flatfile table,
OR we could add our own system table that would be created when one
initializes pg_avd.
I don't want to add tables to existing databases, as I consider that
clutter and I never like
Josh Berkus wrote:
Matthew,
I don't see how a seperate database is better than a table in the databases.,
except that it means scanning only one table and not one per database. For
one thing, making it a seperate database could make it hard to back up and
move your database+pg_avd
Josh Berkus wrote:
Matthew,
I certainly agree that less than 10% would be excessive, I still feel
that 10% may not be high enough though. That's why I kinda liked the
sliding scale I mentioned earlier, because I agree that for very large
tables, something as low as 10% might be useful,
On Fri, 2003-12-12 at 14:51, Andrew Dunstan wrote:
re Windows: pipes, yes, hard links, no (and no sane symlinks either)
Actually, NTFS does support hard links, there is just no support for it
in any MS file management GUI.
On Fri, 2003-12-12 at 15:42, Tom Lane wrote:
Alternative thought: just recommend that if possible, people take
a filesystem dump of their old PGDATA directory after stopping
the old postmaster. This would be sufficient for retreating to
the prior version if needed. It might or might not be
On Fri, 2003-12-12 at 14:00, Tom Lane wrote:
Currently the no-table-contents-changes restriction keeps us from
upgrading from versions older than 7.4 anyway (since type NUMERIC had its
on-disk representation changed in 7.4). We could possibly upgrade 7.3
databases that contain no NUMERIC
On Sun, 2003-12-14 at 18:02, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
How limiting is the above? Does this mean that pg_upgrade will be
rendered invalid if there is an on-disk representation change? Do we
think we will make it from 7.4 - 7.5 without on-disk changes
Christopher Kings-Lynne wrote:
What's the best way to do log rolling with pg_autovacuum? It doesn't
seem to have any syslog options, etc. Using 'tee' maybe?
I got an email from Mark Hollow saying that he had implemented a syslog
patch for pg_autovacuum. Don't know how good it is, but it
Thomas Swan wrote:
I just thought the anecdote of confusing it for an MTA was a little funny.
Funny yes, but unfortunatly all too common for newbies I think.
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Mon, 2004-01-19 at 08:37, Jan Wieck wrote:
but I will not waste my time with making patches nobody even gives a try.
I downloaded and tested your patches. I just didn't get results get
results that were put together well enough to present to the group. I
hope this doesn't fall by the
Yeah, I'll take a look at it and submit a patch. Sorry I didn't see it
sooner, but I don't read the bugs mailing list.
On Wed, 2004-02-11 at 17:29, Bruce Momjian wrote:
Would someone review these problems and submit a patch? Thanks.
On Wednesday 03 March 2004 10:11 pm, Bruce Momjian wrote:
I have caught up on my email and am working on the 7.4.2 branding now.
Ack is it too late to submit a patch to fix the int overflow problem with
pg_autovacuum? I'll send a patch to the patches list shortly, hopefully it
will get
On Thursday 04 March 2004 12:04 am, Tom Lane wrote:
I thought we'd fixed that problem already though. Is there another?
Don't know if it's another, but the problem posted by Cott Lang on 1/17
( http://archives.postgresql.org/pgsql-bugs/2004-01/msg00111.php )
has not been resolved.
I know Bruce did the RELEASE NOTES and all that week bit early, so I
just want to make sure there is nothing outstanding before I package her
up ...
I'll do it around midnight GMT tonight baring any raised hands ...
I was hoping to have the pg_autovacuum fixes commited, but Tom found some
[moving to hackers]
Line 681 is this:
sprintf(logbuffer, dbname: %s Username %s Passwd %s,
dbi-dbname, dbi-username, dbi-password);
It appears that dbi-password is a null pointer:
(gdb) print dbi-dbname
$1 = 0x25f68 template1
(gdb) print dbi-username
$2 =
Lately I have been thinking about the next steps for the pg_autovacuum
daemon. I have written up a document that describes what I'm planning
to do next. Please read the attached and response as I would really
like some feedback.
Thanks,
Matthew O'Connor
pg_autovacuum_v2_writeup.rtf
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process). Then you have access to a host of methods for
storing state,
On Sun, 2004-03-21 at 18:12, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
[ rtf document ]
Please repost in some less proprietary format. Plain text is generally
considered the thing to use on this list.
I don't think RTF is proprietary but I should have just posted
On Mon, 2004-03-22 at 03:36, Gavin Sherry wrote:
One point is this: vacuum() assumes that you are running in a fully
fledged backend. There'd be a fair bit of work involved in allowing a
single process to call vacuum() against multiple databases.
I can't imagine we want to do that.
As such,
On Mon, 2004-03-22 at 07:25, Richard Huxton wrote:
On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
1.Store config data inside a special pg_autovacuum table inside
existing databases that wants custom settings.
2.Use a config file. This would require some additional coding
On Mon, 2004-03-22 at 04:23, Karel Zak wrote:
All. It's important do it as backend process. Because libpq has very,
very limited and slow resources for work with backend stuff.
Agreed.
The base should be the standard backend with different main loop that
will instead socket checks
On Mon, 2004-03-22 at 10:51, Tom Lane wrote:
2.Use a config file. This would require some additional coding to add
the required parsing, but is possible.
Personally I like #2. The claim that this requires extra code seems
bogus to me --- when you are working at the C code level,
Tom Lane wrote:
From the point of view of the postmaster a GUC-controlled delay would
seem like the best thing. We could discuss having the autovacuum code
try to feed back adjustments in the delay, but remember that one of the
golden virtues for the postmaster proper is simplicity; that
Alex J. Avriette wrote:
Hi, Matthew. For our uses, we found that pg_autovacuum did not behave
as expected with vacuum_threshold set to 0. For our purposes, we have
a very good idea of how many tuples need to be slurped up over a given
interval, and would like the autovacuum daemon to simply go
Tom Lane wrote:
If you aren't a backend then you couldn't safely access shared memory,
including FSM in particular. I see no reason you couldn't use GUC
though. There is no direct pipe connection to the stats collector,
except in the output direction which is not what you want, so I'm not
Joe Conway wrote:
Matthew T. O'Connor wrote:
* Inability to schedule vacuums during off-peak times
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal
Gavin Sherry wrote:
I was initially against the idea of using libpq but its growing on me too.
I think it would be good if the core functions of pg_autovacuum: threshold
algorithms, connection, issuing commands can be (re?)designed such that
not only the backend can link against it but also a
Josh Berkus wrote:
Inability to customize thresholds on a per table basis
This hasn't been a big problem for me. I would judge that 80% of my clients
would make no use of this feature.
Ok.
Inability to set default thresholds on a per database basis
This would be much more useful
Josh Berkus wrote:
Syslog support. I'm not sure this is really needed, but a simple patch was
submitted by one user and perhaps that can be reviewed / improved and
applied.
I need it, and am glad to hear there is a patch. Several of my clients use
centralized syslog servers, and do
On Tuesday 23 March 2004 12:32 am, Josh Berkus wrote:
Matt,
What I'm thinking is that the VACUUM command could be modified to write
down some data from the stats system at vacuum time. Once the VACUUM
command writes this down for itself then pg_autovacuum just uses that
number to make
I'm wondering who's doing the PostgreSQL on Windows page
(http://techdocs.postgresql.org/guides/Windows). I wanted to offer to
add the OleDB project to the Connecting your Windows applications to
PostgreSQL http://techdocs.postgresql.org/guides/PostgreSQL section.
Would probably be good to
On Wednesday 24 March 2004 06:03 pm, Dustin Sallings wrote:
There's not a lot of GUI in arch, but star-merge is fairly incredible.
This is how tla (the main arch implementation) itself is developed.
Lots of branches in lots of archives by lots of people.
I would guess that better
Bruce Momjian wrote:
Tom Lane wrote:
Don't hold your breath ... 7.4.2 was only a couple weeks ago, and there
are no critical bugs in the CVS logs at this point.
The only post-7.4.2 Solaris fixes I can think of are for threaded
builds. Do you use those? If so, you can grab CVS
Bruce Momjian wrote:
Should pg_autovacuum be vacuuming temporary tables?
This is a good question, and I would like some opinions from some other
people more informed than I.
Secondly, why would
a temporary table for another session be visible to pg_autovacuum? I
know these may sound like
Yeah, I will, I just don't know when. I have been trying to get to this
and lots of other pg_autovacuum tasks, but my schedule has been quite
crazy as of late. Anyway, this should probably be a pretty simple patch,
so I can probably find some time to look at it soon.
Any idea on the 7.4.3
Christopher Kings-Lynne wrote:
Does pg_autovacuum vacuum and analyze system catalog and TOAST tables
properly?
Properly? I think so, that is to the best of my knowledge which is a
bit limited :-)
Toast Tables: pg_autovacuum doesn't do anything to toast tables
explicitly. I am not aware
Bruce Momjian wrote:
No, I have not heard of a 7.4.3 timeline, but we certainly want your
eventual fixes in that release.
Right, and along these lines there are a few other pg_autovacuum bugs
that were fixed just after 7.4.2.
---(end of
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
This is a good question, and I would like some opinions from some other
people more informed than I.
You *can not* vacuum other sessions' temp tables; you don't have access
to the data. (You have no way to get at pages
On Wednesday 21 April 2004 12:05 am, Christopher Kings-Lynne wrote:
No, I have not heard of a 7.4.3 timeline, but we certainly want your
eventual fixes in that release.
Right, and along these lines there are a few other pg_autovacuum bugs
that were fixed just after 7.4.2.
A rollable
Joshua D. Drake wrote:
Hello,
My personal opinion is that contrib should be removed entirely. Just
have a contrib.txt that says all contrib modules are at pgfoundry or
whatever.
I'm not so sure that's a good idea. I think contrib is a good
repository for code that is tightly tied to the
There are two issues here : ease-of-use for admin and basic users.
On for former point, admin ease-of-use, A little story a few month ago.
I succeeded in advising production people here to switch some applications
from a mysql database, which was working perfectly, to a postgres
database. A
My goal is to have pg_autovacuum integrated into the backend for 7.5.
I know about that, and that would be a good thing.
I hope so!
I don't know if it will default to being turned on or off, I'm sure that
will be a discussion, but if it is defaulted to on, then this whole
problem of having
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
No the current implementation doesn't, but such a feature is in the works
(planned anyway). What I was
On Fri, 23 Apr 2004 11:07:20 -0400
Dave Cramer [EMAIL PROTECTED] wrote:
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
It seems to me that the point of
On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
The difference is that a better admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a better admin tool, but
very few can really argue as to a
Dave Page wrote:
Any comments/criticisms/gasps of horror at all the win32 code? :-)
Sorry for not jumping in sooner but I have been offline for several days.
Anyway, not having looked at this at all, how will this be effected when
pg_autovacuum is integrated into the backend. I assume that
Marc G. Fournier wrote:
On Thu, 29 Apr 2004, Matthew T. O'Connor wrote:
I know it's a chicken and egg problem, do we set a date for developers
to shoot for, or do shoot for specific features and choose a date from
there. I think there can no hard and fast rule on this, it depends
On Tue, 2004-04-27 at 09:27, Bruce Momjian wrote:
Here are features that are being worked on, hopefully for 7.5:
o tablespaces (Gavin)
o nested transactions (Alvaro)
o two-phase commit (Heikki Linnakangas)
o integrated pg_autovacuum (O'Connor)
o PITR
Bruce Momjian wrote:
Yes, it was vague. The question is now that we are a month away, do we
want to target June 1, mid-June, or July 1.
Some are saying that once Win32 is ready, it will justify a release even
if the other features are not ready.
I think we should have this conversation once the
Bruce Momjian wrote:
Well, if Win32 doesn't complete by June 1, do we still do the feature
freeze? I don't want to be adding features after the freeze, that is
for sure. When we have done that in the past, it has caused problems
because some stuff gets in to make the system unstable, but other
Jeff Boes wrote:
We noticed that one of our high-volume insert tables was being vacuumed
every time pg_autovacuum woke up. (Im running it with the default
threshold values, and a 900-second sleep cycle.) The table has a few
million rows in it. With debug = 2 on, here's what the pg_autovacuum
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I probably said that wrong, but how do backends get their stats data?
They read it out of a flat file that the stats collector rewrites every
so often.
Ok so that would be easy to do (if we decide we want to)
Is that really
On Tue, 2004-05-18 at 22:21, Brian Hirt wrote:
there might be another similar bug that was fixed in 7.4.2
This bug is fixed, but it didn't make in 7.4.2, it is in CVS (both 7.4
and HEAD). Please grab pg_autovacuum.c and .h from CVS, if that doesn't
fix it please let me know.
Thanks,
Matthew
,
Matthew T. O'Connor
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
It doesn't have to make its way into the postgresql daemon itself -- in
fact since some people like tuning the vacuuming, it makes more sense to
make this a daemon. No, my suggestion is simple that some sort of
auto-vacuumer be compiled as a stand-alone app and included in the standard
From: Tom Lane [EMAIL PROTECTED]
However, if we are going to put that kind of knowledge into pg_dump,
it would only be a small further step to have it dump these triggers
as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
better for forward compatibility than dumping the
Are you compiling from CVS or from a released tarball? The bison
requirement was recently raised to bison 1.5 or above (1.75 was recently
released also.) This is an issue only when compiling from CVS, since
the bison stuff is preprocessed for released tarballs. So you might
want to try the just
On Wed, 2002-11-06 at 01:32, Justin Clift wrote:
Bruce Momjian wrote:
I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.
Now that 7.3 is almost complete, I am
Tom, would you really be able to ask Permaine to retest 7.3? Have a
feeling we might be able to leverage the PlayStation2 brand name here
for the Advocacy project.
:-)
Anyone try it on an Xbox yet?
---(end of broadcast)---
TIP 6: Have you
Several months ago tried to implement a special postgres backend as an
Auto Vacuum Daemon (AVD), somewhat like the stats collector. I failed
due to my lack of experience with the postgres source.
On Sep 23, Shridhar Daithankar released an AVD written in C++ that acted
as a client program
On Thu, 2002-11-28 at 01:58, Shridhar Daithankar wrote:
There are differences in approach here. The reason I prefer polling rather than
signalig is IMO vacuum should always be a low priority activity and as such it
does not deserve a signalling overhead.
A simpler way of integrating would
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to put on this system. It might make sense to say allow upto X
On Friday 29 November 2002 00:56, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
But we already have a recycling mechanism for pg_clog. AFAICS,
creating a parallel log file with a separate recycling mechanism is
a study in wasted effort.
But that recycling
pg_dump, our upgrade process is painful enough having to do a dump, reload.
I think we should be able to guarantee (or at least let much closer to it)
that the process works in all cases.
Personally pg_upgrade would be even nicer.
- Original Message -
From: Christopher Kings-Lynne [EMAIL
- Original Message -
From: Shridhar Daithankar [EMAIL PROTECTED]
To: Matthew T. O'Connor [EMAIL PROTECTED]
Sent: Monday, December 02, 2002 11:12 AM
Subject: Re: [HACKERS] Auto Vacuum Daemon (again...)
On 28 Nov 2002 at 3:02, Matthew T. O'Connor wrote:
I went thr. it today and I have
\Dsomething works though.)
Any objections out there?
My only complaint here is being forced to use the 'shift' key on commands
that will be common.
\dd perhaps?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
On Tue, 2003-02-11 at 13:01, Tom Lane wrote:
Jon Griffin [EMAIL PROTECTED] writes:
So it appears that linux at least is way above your 8 meg point, unless I
am missing something.
Yeah, AFAIK all recent Linuxen are well above the range of parameters
that I was suggesting (and even if they
PS: Another idea I'm toying with is to dump out the FSM contents at
postmaster shutdown and reload them at restart, so that the FSM doesn't
have to start from ground zero on every restart cycle. But that's
independent of the management algorithm...
Correct me if I'm wrong, but the FSM is
However, others don't believe constraints other than foreign keys
should go unchecked.
That said, is this functionality wanted outside of pg_dump /
pg_restore?
pg_dump should reload a database as it was stored in the previous database.
If your old data is not clean, pg_dump / restore is
From the ToDo list:
Vacuum: * Provide automatic running of vacuum in the background (Tom)
As of 7.2 we have lazy vacuum. The next logical step is setting up vacuum to
run automatically in the background either as some type of daemon or as
something kicked off by the postmaster.
I am
On Saturday 29 June 2002 08:14 pm, Tom Lane wrote:
Launching VACUUMs on some automatic schedule, preferably using feedback
about where space needs to be reclaimed, seems like a pretty
straightforward small-matter-of-programming. The thing that would
really be needed to make it unobtrusive is
Keys to this working:
1.) Must not require the old version executable backend. There are a
number
of reasons why this might be, but the biggest is due to the way much
upgrading works in practice -- the old executables are typically gone by
the
time the new package is installed.
On Mon, 2002-07-29 at 08:53, [EMAIL PROTECTED] wrote:
Just a long standing curiosity?
e) Inertia. MySQL got more popular way back when; the reasons may no longer
f) Win32 Support. I can download a setup.exe for mysql and have it up
and running quickly on Windows. I think that native Win32
I have been getting this for at least two days:
[matthew@zeut src]$ cvs -v
Concurrent Versions System (CVS) 1.11.2 (client/server)
[matthew@zeut src]$ cvs -z3 -d
:pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql
[...]
cvs server: Updating
Hello, I'm playing with creating an auto vacuum daemon, but it is my first
time inside the pg source code and I'm a bit lost.
I have gotten as far as having a vacuum daemon created on postmaster startup.
It's just a fork from the postmaster, cribbed mostly from the stat collector
code.
when I feel more confident as to what I'm
talking about.
On Friday 16 August 2002 10:10 am, Jan Wieck wrote:
Matthew T. O'Connor wrote:
Hello, I'm playing with creating an auto vacuum daemon, but it is my
first time inside the pg source code and I'm a bit lost.
I have gotten as far
Anyone want to argue that we should keep the v0 protocol support any
longer?
Nope, exactly the same thought crossed my mind while I was reading
through the code...
Feel free to rip it out.
Should probably be mentioned in the release notes.
---(end of
On Saturday 07 September 2002 12:52 pm, Bruce Momjian wrote:
Peter Eisentraut wrote:
Didn't we want to remove that option?
I didn't know it was still in there. I see no reason for it.
How about --enable-depend, that's not still needed is it? Or is that
something other than the new
Hello, I'm having a problem vacuum a table and I didn't see an answer using
the fts engine.
I have two questions:
1) Is this a big problem, can it be fixed, do I have to dump / restore this
table?
2) I found this problem from my nightly cron driven vacuum -a -z. When it
hits this error the
Yes and no :-). The files were created but all postgres data files are now
idententified by numbers (oids I think), so you will not find a file or
directory anywhere in your filesystem named mydb, or mytable.
- Original Message -
From: Peter Moscatt [EMAIL PROTECTED]
To: [EMAIL
I disagree. Unless you are omniscient, we will only ever have a
partial
list.
but there wasn't enough interest for someone to take on
the maintenance.
We need someone willing to be a kibo. Or is that too arcane a reference?
Gotta admit, I haven't heard that in a while. But
Actually, the 'multi-day' delay is generally related to posts from ppl
that aren't subscribed to the lists that I have to approve manually ...
I have been getting delayed duplicates from people (ie, Tom Lane)
addressed
to only the hackers list (which I know he's subscribed to). Up to a
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
On Sat, 2004-05-22 at 23:44, Mark Kirkwood wrote:
We could perhaps do something similar to the Apache 1.3 win platform
notes, where they (still) say *something* like :
Apache on windows is not as stable as on unix... but is being actively
improved all the time
This is a bit more
I certainly get the feeling that things are being rushed just a bit too
much, and think having a extra few days of breathing space makes sense.
cheers
andrew
I have that feeling too, and I'm working still working on pg_autovacuum
integration which I was hoping to get in, so I would welcome
Since the Feature Freeze is coming on quickly and I have yet to submit a
patch that integrated pg_autovacuum into the backend (though I have been
working on it), I wanted to see what people thing about a few things.
Since we are nearing feature freeze, I know won't complete all the
improvements
1 - 100 of 301 matches
Mail list logo
