Re: [PATCHES] [DOCS] OS/X startup scripts

On Sun, 2007-13-05 at 18:58 -0700, David Fetter wrote: > cvs diff works just great until you want to add or remove a file > without write permissions to the CVS repository, i.e. when you've > checked out as anonymous. Personally, I usually work against a checkout from a local mirror of the CVS rep

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

On Sun, 2007-13-05 at 22:06 -0400, Tom Lane wrote: > This fact is already documented in at least three places; do we really > need two more? I think we need to at least modify the documentation for the autovacuum GUC parameter, which currently states only that it "controls whether the server shoul

Re: [PATCHES] Updateable cursors patch

On 4/4/07, FAST PostgreSQL <[EMAIL PROTECTED]> wrote: Attached is a working updateable cursors patch. The core functionality has been implemented and the patch also contains the regression tests and documentation. this one doesn't apply cleanly to HEAD because of the changes in http://archives

Re: [PATCHES] [DOCS] OS/X startup scripts

David Fetter wrote: cvs diff works just great until you want to add or remove a file without write permissions to the CVS repository, i.e. when you've checked out as anonymous. I usually saved an untouched version of the tree to compare against, so something like: $ cvs diff -Nacr pgsql.ori

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

On Sun, May 13, 2007 at 10:06:40PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > Per Neil Conway, here's some doc patches re: the autovacuum > > daemon's behavior. Should this be back-patched to 8.2x? > > This fact is already documented in at least three places; do we > re

Re: [PATCHES] [DOCS] Autovacuum and XID wraparound

David Fetter <[EMAIL PROTECTED]> writes: > Per Neil Conway, here's some doc patches re: the autovacuum daemon's > behavior. Should this be back-patched to 8.2x? This fact is already documented in at least three places; do we really need two more? The proposed addition to postgresql.conf seems pa

Re: [PATCHES] [DOCS] OS/X startup scripts

On Sun, May 13, 2007 at 09:51:53PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Sun, May 13, 2007 at 07:04:44PM -0400, Andrew Dunstan wrote: > >> Tom Lane wrote: > >>> Strange, it works fine for everyone else. > >> > >> Especially if you have cvsutils installed (can be

[PATCHES] On patching without write access to CVS

Folks, Thanks to Andrew Dunstan for pointing me toward cvsutils. As not everybody knows about them, here's a small patch which lets people know at least in theory where they are. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666

Re: [PATCHES] Concurrent psql patch

Gregory Stark <[EMAIL PROTECTED]> writes: > So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that > previously since I'm not accustomed to using \g but it does seem kind of > pretty. I normally use ; but I suppose there's nothing wrong with just > declaring that asynchronous

Re: [PATCHES] [DOCS] OS/X startup scripts

David Fetter <[EMAIL PROTECTED]> writes: > On Sun, May 13, 2007 at 07:04:44PM -0400, Andrew Dunstan wrote: >> Tom Lane wrote: >>> Strange, it works fine for everyone else. >> >> Especially if you have cvsutils installed (can be found in many >> places including fedora extras). > I didn't know abo

Re: [PATCHES] [DOCS] OS/X startup scripts

On Sun, May 13, 2007 at 07:04:44PM -0400, Andrew Dunstan wrote: > > > Tom Lane wrote: > >David Fetter <[EMAIL PROTECTED]> writes: > > > >>I haven't included the customary diffs. This points me to some of > >>the many deficiencies of CVS, namely that I would need write > >>access in order to ha

[PATCHES] Autovacuum and XID wraparound

Folks, Per Neil Conway, here's some doc patches re: the autovacuum daemon's behavior. Should this be back-patched to 8.2x? Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

Heikki Linnakangas <[EMAIL PROTECTED]> writes: >>> Or we could switch to a more compact representation of the dead tuples, >>> and not need such a big maintenance_work_mem in the first place. > One idea is to use a compressed bitmap like in the bitmap index patch, > and a tree of block numbers o

Re: [PATCHES] Concurrent psql patch

"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "David Fetter" <[EMAIL PROTECTED]> writes: >>> What's the reasoning behind \c&? Does it "send things into the >>> background" the way & does in the shell? > >> Sort of. It sends the *subsequent* command to the b

Re: [PATCHES] [DOCS] OS/X startup scripts

Tom Lane wrote: David Fetter <[EMAIL PROTECTED]> writes: I haven't included the customary diffs. This points me to some of the many deficiencies of CVS, namely that I would need write access in order to have it create a diff, Strange, it works fine for everyone else.

Re: [PATCHES] [DOCS] OS/X startup scripts

David Fetter <[EMAIL PROTECTED]> writes: > I haven't included the customary diffs. This points me to some of the > many deficiencies of CVS, namely that I would need write access in > order to have it create a diff, Strange, it works fine for everyone else. regards, tom l

Re: [PATCHES] Concurrent psql patch

Gregory Stark <[EMAIL PROTECTED]> writes: > "David Fetter" <[EMAIL PROTECTED]> writes: >> What's the reasoning behind \c&? Does it "send things into the >> background" the way & does in the shell? > Sort of. It sends the *subsequent* command to the background... That sounds just bizarre. Existi

Re: [PATCHES] Concurrent psql patch

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote: >> >> I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. >> I'm >> not sure if going for cryptic short commands is better or worse here. > > \c& sounds fine (as do

Re: [PATCHES] Concurrent psql patch

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote: > "Jim Nasby" <[EMAIL PROTECTED]> writes: > > > I don't see how we could make the names shorter without moving away from a > > backslash command (which I'm guessing would be painful). > > > > Assuming we're stuck with a backslash comma

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

On Sun, May 13, 2007 at 11:19:07AM +0100, Heikki Linnakangas wrote: > Jim C. Nasby wrote: > >On Sat, May 12, 2007 at 07:57:44PM +0100, Heikki Linnakangas wrote: > >>Or we could switch to a more compact representation of the dead tuples, > >>and not need such a big maintenance_work_mem in the first

[PATCHES] OS/X startup scripts

Folks, The attached tarball should be unpacked in contrib/startup-scripts, and supplants PostgreSQL.darwin and StartupParameters.plist.darwin. Thanks to Mark Cotner of Reflectr fame for this update :) I haven't included the customary diffs. This points m

Re: [PATCHES] Concurrent psql patch

"David Fetter" <[EMAIL PROTECTED]> writes: >> I was originally thinking \c1, \c2, ... for \cswitch and \c& for >> \cnowait. I'm not sure if going for cryptic short commands is better >> or worse here. > > +1 for \c1, \c2, etc. > > What's the reasoning behind \c&? Does it "send things into the > b

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

On Sun, 13 May 2007, Heikki Linnakangas wrote: StrategyReportWrite increments numClientWrites without holding the BufFreeListLock, that's a race condition. The terminology needs some adjustment; clients don't write buffers, backends do. That was another piece of debugging code I moved into th

Re: [PATCHES] Concurrent psql patch

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote: > "Jim Nasby" <[EMAIL PROTECTED]> writes: > > > I don't see how we could make the names shorter without moving > > away from a backslash command (which I'm guessing would be > > painful). > > > > Assuming we're stuck with a backslash c

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

Greg Smith wrote: The original code came from before there was a pg_stat_bgwriter. The first patch (buf-alloc-stats) takes the two most interesting pieces of data the original patch collected, the number of buffers allocated recently and the number that the clients wrote out, and ties all that

Re: [PATCHES] Doc update for back-branches, CLUSTER and MVCC-safety

Heikki Linnakangas wrote: > I posted a doc update a while ago to mention that CLUSTER isn't MVCC-safe: > > http://archives.postgresql.org/pgsql-patches/2007-03/msg00137.php > > CLUSTER is now MVCC-safe in CVS HEAD, but the documentation for older > releases should still be updated. > Applied to

Re: [PATCHES] Concurrent psql patch

"Jim Nasby" <[EMAIL PROTECTED]> writes: > I don't see how we could make the names shorter without moving away from a > backslash command (which I'm guessing would be painful). > > Assuming we're stuck with a backslash command \cs[witch] and \cn > [owait] seem to be about as good as we could get.

Re: [PATCHES] ECPG patch to use prepare for improved performance

This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- William Lawrance wrote: > > This updated patch for ECPG uses the current routines by > default. If an environment v

Re: [PATCHES] updated WIP: arrays of composites

TODO marked as done: o -Add support for arrays of complex types I assume this is _not_ done, as stated below: o Add support for arrays of domains I will add a URL for this item: http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

Jim C. Nasby wrote: On Sat, May 12, 2007 at 07:57:44PM +0100, Heikki Linnakangas wrote: Or we could switch to a more compact representation of the dead tuples, and not need such a big maintenance_work_mem in the first place. Sure, but even with a more compact representation you can still run o

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Or we could switch to a more compact representation of the dead tuples, and not need such a big maintenance_work_mem in the first place. Hm, you got any ideas? One constraint is that it doesn't seem acceptable to make the search f