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
"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,
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I assume we want to gather the statistics per resource (represented by
> LWLockKind in my patch), not per LWLockId.
Why? I haven't yet seen any problem where that looked useful.
The named LWLocks are certainly sui generis, and as for things like
per-
"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 resour
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:
a
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 this
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
-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 an
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
>
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
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 it
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 of
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()::nu
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 lo
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=hyena&dt=2006-07-19%2009:20:00
The symptom is always that one of the tests fails entirely because
psql couldn't connect:
psql
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=hyena&dt=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 t
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 accur
# 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
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'
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 ...
20 matches
Mail list logo
