Re: [HACKERS] Experimental patch for inter-page delay in VACUUM

2003-11-03 Thread Matthew T. O'Connor
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

Re: [HACKERS] Experimental patch for inter-page delay in VACUUM

2003-11-04 Thread Matthew T. O'Connor
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

Re: [HACKERS] Performance features the 4th

2003-11-05 Thread Matthew T. O'Connor
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

Re: [HACKERS] Performance features the 4th

2003-11-07 Thread Matthew T. O'Connor
- 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

Re: [HACKERS] bugzilla (Was: What do you want me to do?)

2003-11-11 Thread Matthew T. O'Connor
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

Re: [HACKERS] rpm support for 7.4 and beyond

2003-11-12 Thread Matthew T. O'Connor
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?

Re: [HACKERS] Release cycle length

2003-11-17 Thread Matthew T. O'Connor
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

Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

2003-11-17 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
Shridhar Daithankar wrote: Matthew T. O'Connor wrote: But we track tuples because we can compare against the count given by the stats system. I don't know of a way (other than looking at the FSM, or contrib/pgstattuple ) to see how many dead pages exist. I think making pg_autovacuum dependent

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] More detail on settings for pgavd?

2003-11-21 Thread Matthew T. O'Connor
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,

Re: [HACKERS] Resurrecting pg_upgrade

2003-12-12 Thread Matthew T. O'Connor
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.

Re: [HACKERS] Resurrecting pg_upgrade

2003-12-12 Thread Matthew T. O'Connor
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

Re: [HACKERS] Resurrecting pg_upgrade

2003-12-12 Thread Matthew T. O'Connor
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

Re: [HACKERS] Resurrecting pg_upgrade

2003-12-14 Thread Matthew T. O'Connor
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

Re: [HACKERS] Log rotation for pg_autovacuum

2004-01-15 Thread Matthew T. O'Connor
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

Re: [HACKERS] nomenclature

2004-01-16 Thread Matthew T. O'Connor
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

Re: [HACKERS] VACUUM delay (was Re: What's planned for 7.5?)

2004-01-19 Thread Matthew T. O'Connor
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

Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?

2004-02-11 Thread Matthew T. O'Connor
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.

Re: [HACKERS] 7.4.2 branding

2004-03-03 Thread Matthew T. O'Connor
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

Re: [HACKERS] 7.4.2 branding

2004-03-03 Thread Matthew T. O'Connor
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.

Re: [HACKERS] 7.4.2 ... all commits in?

2004-03-07 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PERFORM] rapid degradation after postmaster restart

2004-03-16 Thread Matthew T. O'Connor
[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 =

[HACKERS] pg_autovacuum next steps

2004-03-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-21 Thread Matthew T. O'Connor
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,

Re: [HACKERS] pg_autovacuum next steps

2004-03-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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,

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
On Mon, 2004-03-22 at 10:58, Tom Lane wrote: Lots of idle processes sitting around is right out, too. Remember that each one would eat a backend connection slot. I think we are going to have to limit this to *one* process at a time. What that probably means is that we successively launch an

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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,

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] [DEFAULT] Daily digest v1.4346 (20 messages)

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] [DEFAULT] Daily digest v1.4346 (20 messages)

2004-03-22 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum

2004-03-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] postgres on windows page update

2004-03-23 Thread Matthew T. O'Connor
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

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

2004-03-24 Thread Matthew T. O'Connor
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

Re: [HACKERS] Timeline for 7.4.3?

2004-03-28 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp

2004-04-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp tables

2004-04-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp tables

2004-04-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp tables

2004-04-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp

2004-04-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum crashes when query fails for temp tables

2004-04-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum Win32 service patch #2

2004-05-13 Thread Matthew T. O'Connor
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

Re: [HACKERS] Call for 7.5 feature completion

2004-04-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] 7.5 features

2004-04-27 Thread Matthew T. O'Connor
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

Re: [HACKERS] Call for 7.5 feature completion

2004-04-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] Call for 7.5 feature completion

2004-04-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum misinterpreting reltuples?

2004-05-05 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum next steps

2004-05-17 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_autovacuum seems to be a neat freak and cleans

2004-05-18 Thread Matthew T. O'Connor
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

[HACKERS] Downloadable Mailing List Archives

2004-05-21 Thread Matthew T. O'Connor
, 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])

Re: [HACKERS] Postgresql Automatic vacuum

2002-09-24 Thread Matthew T. O'Connor
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

Re: [HACKERS] Reconstructing FKs in pg_dump

2002-09-27 Thread Matthew T. O'Connor
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

Re: [HACKERS] Request for supported platforms

2002-10-28 Thread Matthew T. O'Connor
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

Re: [HACKERS] Win32 port

2002-11-05 Thread Matthew T. O'Connor
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

Re: [HACKERS] RC1?

2002-11-14 Thread Matthew T. O'Connor
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

[HACKERS] Auto Vacuum Daemon (again...)

2002-11-26 Thread Matthew T. O'Connor
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

Re: [HACKERS] Auto Vacuum Daemon (again...)

2002-11-28 Thread Matthew T. O'Connor
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

Re: [HACKERS] Auto Vacuum Daemon (again...)

2002-11-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] nested transactions

2002-11-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] 7.4 Wishlist

2002-11-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] Auto Vacuum Daemon (again...)

2002-12-02 Thread Matthew T. O'Connor
- 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

Re: [HACKERS] psql's \d commands --- end of the line for

2002-12-09 Thread Matthew T. O'Connor
\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

Re: [HACKERS] Changing the default configuration (was Re: [pgsql-advocacy]

2003-02-11 Thread Matthew T. O'Connor
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

Re: [HACKERS] Free-space-map management thoughts

2003-02-26 Thread Matthew T. O'Connor
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

Re: [HACKERS] pg_dump and ALTER TABLE / ADD FOREIGN KEY

2002-06-22 Thread Matthew T. O'Connor
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

[HACKERS] Vacuum Daemon

2002-06-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] Vacuum Daemon

2002-06-29 Thread Matthew T. O'Connor
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

Re: [HACKERS] (A) native Windows port

2002-07-02 Thread Matthew T. O'Connor
The question is not how to replace some .EXE and .DLL files or modify something in the registry. The question is what to do with the existing databases in the case of a catalog version change. You have to dump and restore. pg_upgrade? Otherwise: no upgrades persay, but you can intall the

Re: [HACKERS] (A) native Windows port

2002-07-09 Thread Matthew T. O'Connor
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.

Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?

2002-07-30 Thread Matthew T. O'Connor
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

[HACKERS] More CVS Problems

2002-08-14 Thread Matthew T. O'Connor
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

[HACKERS] Coding help

2002-08-15 Thread Matthew T. O'Connor
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.

Re: [HACKERS] Coding help

2002-08-16 Thread Matthew T. O'Connor
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

Re: [HACKERS] [PATCHES] fix for palloc() of user-supplied length

2002-08-28 Thread Matthew T. O'Connor
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

Re: [HACKERS] --with-maxbackends

2002-09-07 Thread Matthew T. O'Connor
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

Re: [HACKERS] Plans for solving the VACUUM problem

2001-05-17 Thread Matthew T. O'Connor
Free space map details -- Accesses to the FSM could create contention problems if we're not careful. Another quick thought for handling FSM contention problems. A backend could give up waiting for access to the FSM after a short period of time, and just append it's data

[HACKERS] Help with Vacuum Failure

2001-08-14 Thread Matthew T. O'Connor
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

Re: [HACKERS] CREATEDB Where ??

2001-08-20 Thread Matthew T. O'Connor
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

Re: [HACKERS] Link to bug webpage

2001-08-21 Thread Matthew T. O'Connor
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

Re: [HACKERS] List response time...

2001-08-22 Thread Matthew T. O'Connor
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

  1   2   3   4   >