Greg Stark wrote:
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggssi...@2ndquadrant.com wrote:
WALInsertLock is heavily contended and likely always will be even if we
apply some of the planned fixes.
I've lost any earlier messages, could you resend the raw data on which
this is based?
I don't
Heikki Linnakangas wrote:
Greg Stark wrote:
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggssi...@2ndquadrant.com wrote:
WALInsertLock is heavily contended and likely always will be even if we
apply some of the planned fixes.
I've lost any earlier messages, could you resend the raw data on which
Jan Otto as...@me.com writes:
ERROR: could not read directory pg_tblspc/16464: Invalid argument
STATEMENT: DROP TABLESPACE testspace;
I have digged a bit around in the source code of postgresql to build a
self contained test-case for Apple and found that the implementation
of Apples
On 29 Aug 2009, at 18:05, Greg Stark wrote:
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Index: src/include/postgres.h
===
RCS file:
While looking into a pgpool-II problem reported by a user, I found
weird behavior of PQexecPrepared().
Strange thing is, it seems PQexecPrepared() sends B(bind), Describe,
Execute and Sync at once without checking the result of Bind
message. Is this leagal from a point of view of the
On Sun, 2009-08-30 at 09:03 +0300, Heikki Linnakangas wrote:
The Hot Standby thing has been discussed, but no-one has actually posted
a patch which does the locking correctly, where the ProcArrayLock is
held while the SnapshotData WAL record is inserted. So there is no
evidence that it's
okay, I think I nailed the assert part right. (3rd iteration, about
time...).
as usual: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-2/
archive one dir up.
the current patch attached.
postgres_checker_patch.patch.bz2
Description: BZip2 compressed data
--
Sent via
On lör, 2009-08-29 at 17:35 +0100, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never
On Sun, Aug 30, 2009 at 3:26 PM, Peter Eisentrautpete...@gmx.net wrote:
On lör, 2009-08-29 at 17:35 +0100, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
--
greg
http://mit.edu/~gsstark/resume.pdf
diff --git a/src/backend/tsearch/regis.c b/src/backend/tsearch/regis.c
index 8980c2a..e492562 100644
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I can do is this: http://llvm.org/bugs/show_bug.cgi?id=4832
I find it hard to belive
On Sun, Aug 30, 2009 at 3:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I
Tatsuo Ishii is...@postgresql.org writes:
Strange thing is, it seems PQexecPrepared() sends B(bind), Describe,
Execute and Sync at once without checking the result of Bind
message. Is this leagal from a point of view of the frontend/backend
protocol?
Yes. If we failed to do this then every
Jan Otto as...@me.com writes:
The bug in readdir() appeared in the final snow leopard too. Anybody
with Snow Leopard installed can check this, with simply doing the
regression tests (make check). The tablespace regression test is
failing.
The patch i sent in works around the issue. if it is
Greg Stark gsst...@mit.edu writes:
I think most of the remaining false positives are cases where palloc,
palloc0, repalloc, MemoryContextAlloc, or MemoryContextAllocZero
return values are deferenced. Clang doesn't know that these functions
never return NULL so it's marking every case as a
Greg Stark gsst...@mit.edu writes:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead of (exit(1),NULL)
we could just put ((void*)1)
-- Forwarded message --
From: Greg Stark gsst...@mit.edu
To: Simon Riggs si...@2ndquadrant.com
Date: Sun, 30 Aug 2009 00:28:14 +0100
Subject: Re: LWLock Queue Jumping
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggssi...@2ndquadrant.com wrote:
WALInsertLock is heavily
On 30 Aug 2009, at 18:07, Greg Stark wrote:
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead
-- Forwarded message --
From: Stefan Kaltenbrunner ste...@kaltenbrunner.cc
To: Heikki Linnakangas heikki.linnakan...@enterprisedb.com
Date: Sun, 30 Aug 2009 11:48:47 +0200
Subject: Re: LWLock Queue Jumping
Heikki Linnakangas wrote:
Greg Stark wrote:
On Fri, Aug 28, 2009
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
please don't tell me that this is bogus: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
?
How come ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Jeff Janes wrote:
-- Forwarded message --
From: Stefan Kaltenbrunner ste...@kaltenbrunner.cc
To: Heikki Linnakangas heikki.linnakan...@enterprisedb.com
mailto:heikki.linnakan...@enterprisedb.com
Date: Sun, 30 Aug 2009 11:48:47 +0200
Subject: Re: LWLock
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point at
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Yes, it's bogus. ctid is never passed as NULL. It might point at
an invalid itempointer (one with ip_posid == 0). Look at the only
call site.
so why do we check if the pointer is valid ?
[
Bruce,
None of those ideas have gotten a single vote of confidence
from you or Bruce. What's your suggestion?
Another solution would be to make major releases less frequent.
That's not a solution and you know it.
Our development cycle has to change with the growth of the project. I
know
On Sun, Aug 30, 2009 at 11:01 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Jeff Janes wrote:
-- Forwarded message --
From: Stefan Kaltenbrunner ste...@kaltenbrunner.cc
To: Heikki Linnakangas heikki.linnakan...@enterprisedb.com
Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.
Could we change this perhaps so that the full view definition is only
shown with \d+ when the view definition is
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point at
an invalid itempointer (one with ip_posid
Peter Eisentraut pete...@gmx.net writes:
Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.
Could we change this perhaps so that the full view definition is only
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.
Could we change this perhaps so that the full view
Josh Berkus wrote:
Bruce,
None of those ideas have gotten a single vote of confidence
from you or Bruce. What's your suggestion?
Another solution would be to make major releases less frequent.
That's not a solution and you know it.
I do?
Our development cycle has to change with
On Sat, Aug 29, 2009 at 1:05 PM, Bruce Momjianbr...@momjian.us wrote:
Robert Haas wrote:
Both committers and non-committers are currently suffering from the
fact that there is not a lot of time in the year which is set aside
for development, i.e. neither CommitFest-time nor beta-time. To fix
The packager team is planning minor releases of 7.4.X to 8.4.X. The
packaging of the releases will be done on September 3-4, with release
due on September 9 (late to avoid a US holiday on September 7).
Is this likely to include a 64 bit build in the fat binaries for OS X?
--
Andrew McNamara,
The packager team is planning minor releases of 7.4.X to 8.4.X. The
packaging of the releases will be done on September 3-4, with release
due on September 9 (late to avoid a US holiday on September 7).
Is this likely to include a 64 bit build in the fat binaries for OS X?
Ah - after some more
36 matches
Mail list logo
