On Sat, 5 Aug 2006, Peter Eisentraut wrote:
Joshua D. Drake wrote:
Frankly, I don't care if we ever get a bug tracker or use trac.
However a more formalized communication process is sorely needed
IMHO.
There's also supposed to be a wiki set up.
Working on that, hope to have it up Sunday
On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
And what about compression of on-disk sorting?
That's purely a performance issue, which some people seem to want
to define as not a new feature ... which is not *my* view of
what's important
# kleptog@svana.org / 2006-08-05 15:49:33 +0200:
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote:
I have heard you make this argument before, and it is just is not true.
Even Debian is moving toward a more formal structure as has FreeBSD. You
seem stuck in this world where
On Sat, Aug 05, 2006 at 01:00:24PM -0700, Josh Berkus wrote:
Neil, all:
If people are interested in the status of a patch, I think it's
fine for them to email the person who's volunteered to work on it.
The problem I would like to see resolved is that there is currently
no accurate way
I'm noticing that buildfarm member hyena sometimes fails the parallel
regression tests, for instance
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=hyenadt=2006-07-19%2009:20:00
The symptom is always that one of the tests fails entirely because
psql couldn't connect:
psql: could not connect
Tom Lane wrote:
I'm noticing that buildfarm member hyena sometimes fails the parallel
regression tests, for instance
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=hyenadt=2006-07-19%2009:20:00
The symptom is always that one of the tests fails entirely because
psql couldn't connect:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
AFAIK it is not possible for Postgres itself to cause a connection
refused failure --- that's a kernel-level errno. So what's going on
here? The only idea that comes to mind is that this version of Solaris
has some very low limit on
On 7/30/06, Tom Lane [EMAIL PROTECTED] wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
I see the very strange behaviour with the following set of queries:
wsdb=# select na,nb, na::double precision as da, nb::double precision as db
from ( select random()::numeric as na,random()::numeric
Tom Lane wrote:
I see one occurrence in the 8.1 branch on hyena, but the failure
probability seems to have jumped way up in HEAD since we put in the
C-coded pg_regress. This lends weight to the idea that it's a
timing-related issue, because pg_regress.c is presumably much faster
at forking
On Aug 5, 2006, at 10:48 PM, Christopher Browne wrote:
Quoth [EMAIL PROTECTED] (David Fetter):
On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote:
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
While I am not going to reopen the can of worms labeled 'bug
tracker', I think
I see that the installcheck-parallel was not added to the top level
Makefile and Gnumakefile.in when it was added as a regression test
target back in the 8.0 cycle. Is there any objection to my adding it now
so that it is treated the same as the other regression test targets? If
so, should I
Robert Lor [EMAIL PROTECTED] wrote:
CVS head now has the following LWLock probes, and more can easily be
added. These probes can be enabled using the sample DTrace scripts at
http://pgfoundry.org/projects/dtrace/
lwlock-acquire
lwlock-release
lwlock-startwait
lwlock-endwait
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My impression from this post
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php
was that moving it into core should be doable for 8.3. I hope I
didn't misunderstand.
As I've stated before, it sure would be nice if there was any
Greg,
As I've stated before, it sure would be nice if there was any
possible way this could be done for 8.2. This would be a
*huge* feature for
8.2 to have, and it frankly needs all the
big-item-yet-easy-to-grasp features it can get. Is there any
way this could be done if we threw money
Greg Sabino Mullane wrote:
My impression from this post
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php
was that moving it into core should be doable for 8.3. I hope I
didn't misunderstand.
As I've stated before, it sure would be nice if there was any possible
way
A client was recently complaining about problems with not being able to
use a database during a vacuum. It wasn't completely clear what exactly
wasn't working, but what I'm really wondering about is the last status
message:
postgres 1857 0.6 0.8 20964 12900 ? D15:03 0:00 postgres:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Is there any way this could be done if we threw money
and/or people at the problem?
No.
I'm constantly amazed at the way people get worked up about
X-is-not-there *after* feature freeze. If you wanted it in 8.2,
the time to be throwing resources
Jim C. Nasby [EMAIL PROTECTED] writes:
postgres 2038 0.0 0.2 19628 3328 ?S15:04 0:00 postgres:
aspadmin test 192.168.100.7(34223) startup waiting
I've grepped through the source code (grep -ri startup src|grep -i
waiting) and can't find this anywhere...
You wouldn't, because
Tom Lane [EMAIL PROTECTED] wrote:
It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS.
The problem was only postponed.
Can you provide a reproducible test case for this?
This is the reproducible test case:
- Occurs on both 8.1.4 and HEAD.
- On smp machine. I used
19 matches
Mail list logo
