Re: [HACKERS] Upcoming minor releases

>>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

Re: [HACKERS] Upcoming minor releases

>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,

Re: [HACKERS] 8.5 release timetable, again

On Sat, Aug 29, 2009 at 1:05 PM, Bruce Momjian 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 >> this pr

Re: [HACKERS] 8.5 release timetable, again

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 t

Re: [HACKERS] \d+ for long view definitions?

Tom Lane wrote: > Peter Eisentraut 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 defin

Re: [HACKERS] \d+ for long view definitions?

Peter Eisentraut 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 > shown with \

Re: [HACKERS] clang's static checker report.

Grzegorz Jaskiewicz 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 == 0). Look at t

[HACKERS] \d+ for long view definitions?

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 longe

Re: [HACKERS] LWLock Queue Jumping

On Sun, Aug 30, 2009 at 11:01 AM, Stefan Kaltenbrunner wrote: > Jeff Janes wrote: > >>-- Forwarded message -- >>From: Stefan Kaltenbrunner >>To: Heikki Linnakangas >> >>Date: Sun, 30 Aug 2009 11:48:47 +0200 >>Sub

Re: [HACKERS] 8.5 release timetable, again

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

Re: [HACKERS] clang's static checker report.

Grzegorz Jaskiewicz 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 ? [ shrug... ] The mac

Re: [HACKERS] clang's static checker report.

On 30 Aug 2009, at 19:14, Tom Lane wrote: Grzegorz Jaskiewicz 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" itempoin

Re: [HACKERS] LWLock Queue Jumping

Jeff Janes wrote: -- Forwarded message -- From: Stefan Kaltenbrunner To: Heikki Linnakangas mailto:heikki.linnakan...@enterprisedb.com>> Date: Sun, 30 Aug 2009 11:48:47 +0200 Subject: Re: LWLock Queue Jumping Heikki Linnakangas wrote: Greg Stark w

Re: [HACKERS] clang's static checker report.

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: http://www.postgresql.org/mailpref/pgsql-

Re: [HACKERS] clang's static checker report.

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

Re: [HACKERS] LWLock Queue Jumping

> > -- Forwarded message -- > From: Stefan Kaltenbrunner > To: Heikki Linnakangas > 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 at 8:07 PM, Simon Riggs >>> wrote: >>>

Re: [HACKERS] clang's static checker report.

On 30 Aug 2009, at 18:07, Greg Stark wrote: On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewicz> 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 co

Re: [HACKERS] [pgsql-hackers] Daily digest v1.9430 (16 messages)

> > -- Forwarded message -- > From: Greg Stark > To: Simon Riggs > Date: Sun, 30 Aug 2009 00:28:14 +0100 > Subject: Re: LWLock Queue Jumping > On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs wrote: > > WALInsertLock is heavily contended and likely always will be even if we > > apply

Re: [HACKERS] clang's static checker report.

On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewicz 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) there? But I think T

Re: [HACKERS] clang's static checker report.

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

Re: [HACKERS] clang's static checker report.

Greg Stark 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 (pgsql-hackers@postgre

Re: [HACKERS] clang's static checker report.

Greg Stark 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 possible NULL >

Re: [HACKERS] drop tablespace error: invalid argument

Jan Otto 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 not acce

Re: [HACKERS] PQexecPrepared() behavior

Tatsuo Ishii 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 query would involv

Re: [HACKERS] clang's static checker report.

On Sun, Aug 30, 2009 at 3:57 PM, Grzegorz Jaskiewicz 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 can do is th

Re: [HACKERS] clang's static checker report.

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 tho

Re: [HACKERS] clang's static checker report.

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 --

Re: [HACKERS] clang's static checker report.

On Sun, Aug 30, 2009 at 3:26 PM, Peter Eisentraut 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;

Re: [HACKERS] clang's static checker report.

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

Re: [HACKERS] clang's static checker report.

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 pgsql-ha

Re: [HACKERS] LWLock Queue Jumping

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

[HACKERS] PQexecPrepared() behavior

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 frontend/back

Re: [HACKERS] clang's static checker report.

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: /projects/cvsroot/pg

Re: [HACKERS] drop tablespace error: invalid argument

Jan Otto 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 readdir() is buggy.

Re: [HACKERS] LWLock Queue Jumping

Heikki Linnakangas wrote: Greg Stark wrote: On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs 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