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
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
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
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.
I don't
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
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
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 command
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
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
background the way
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
http://pgfoundry.org/projects/reflectr/ fame for this update :)
I haven't included the customary diffs. This points me
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 place.
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 command \cs[witch]
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 \c1...\c9). \g
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. Existing backslash
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 lane
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.
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 background...
That
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 or ranges
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
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 have it create a
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 about those, so
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
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
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 found in many
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
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
really need
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
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
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 should
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
30 matches
Mail list logo
