Re: [HACKERS] Cascade replication

2011-07-05 Thread Simon Riggs
On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao wrote: >> IMHO it's time to get rid of RECOVERYXLOG as an initial target for >> de-archived files. That made sense once, but now we have streaming it >> makes more sense for us to de-archive straight onto the correct file >> name and let the file be cle

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote: > On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis wrote: > > It would be something like: range_co(1,8)::int8range > > > > (just so we're comparing apples to apples) > > > > The intermediate type proposal doesn't require that we move the "c" and > >

Re: [HACKERS] weird cast behavior in "IN (values)" clause

2011-07-05 Thread Tom Lane
Alvaro Herrera writes: > I am not sure why it would be valid to list two literals in the values > but not one. The discrepancy seems to be because transformAExprIn uses a different type resolution method when there's more than one non-Var in the RHS. Maybe we should apply select_common_type even

[HACKERS] weird cast behavior in "IN (values)" clause

2011-07-05 Thread Alvaro Herrera
I just came across this: alvherre=# select * from pg_class where oid::regclass in ('foo'); ERROR: invalid input syntax for type oid: "foo" LÍNEA 1: select * from pg_class where oid::regclass in ('foo'); ^ alvherre=# select * from pg_class wh

Re: [HACKERS] Potential NULL dereference found in typecmds.c

2011-07-05 Thread Alvaro Herrera
Excerpts from Alvaro Herrera's message of lun jul 04 11:12:32 -0400 2011: > Excerpts from Heikki Linnakangas's message of lun jul 04 09:14:11 -0400 2011: > > On 04.07.2011 16:07, Peter Geoghegan wrote: > > > That error message is bogus anyway: > > > > > if (!found) > > > ereport(ERROR

Re: [HACKERS] Cascade replication

2011-07-05 Thread Fujii Masao
On Tue, Jul 5, 2011 at 8:08 PM, Simon Riggs wrote: > Now for the rest of the review... Thanks! > I'd rather not include another chunk of code related to > wal_keep_segments. The existing code in CreateCheckPoint() should be > refactored so that we call the same code from both CreateCheckPoint()

Re: [HACKERS] Crash dumps

2011-07-05 Thread Craig Ringer
On 5/07/2011 9:05 PM, Magnus Hagander wrote: On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote: On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura wrote: I asked about crash reports becaus of at this time there was thread about crashing in live system. Yeah, I thought this was the result of t

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Tom Lane
I wrote: > Another possibility that just occurred to me is to call the validator > like this: > > if (OidIsValid(fdwvalidator)) > { > Datumvalarg = result; > > /* pass a null options list as an empty array */ > if (DatumGetPointer(valarg) == NULL) >

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Tom Lane
Shigeru Hanada writes: > Thanks for the comments. Please find attached a patch. Now file_fdw > validates filename in: > * file_fdw_validator(), to catch lack of required option at DDL > * fileGetOptions(), to avoid crash caused by corrupted catalog Applied with small adjustments.

Re: [HACKERS] Changing extension schema fails silently

2011-07-05 Thread Thom Brown
On 5 July 2011 23:00, Tom Lane wrote: > Thom Brown writes: >> Correction, the objects which belong to the extension do switch >> schema, but the properties of the extension itself indicate the >> extension is in a different schema.  So rather than not working at >> all, it seems that it's just fo

Re: [HACKERS] Changing extension schema fails silently

2011-07-05 Thread Tom Lane
Thom Brown writes: > Correction, the objects which belong to the extension do switch > schema, but the properties of the extension itself indicate the > extension is in a different schema. So rather than not working at > all, it seems that it's just forgotten to update the pg_extension > catalog

Re: [HACKERS] Changing extension schema fails silently

2011-07-05 Thread Thom Brown
On 5 July 2011 22:31, Peter Geoghegan wrote: > From the docs: > > Note that unlike most catalogs with a "namespace" column, extnamespace > is not meant to imply that the extension belongs to that schema. > Extension names are never schema-qualified. Rather, extnamespace > indicates the schema that

[HACKERS] Moving the community git server

2011-07-05 Thread Magnus Hagander
Sometime later this week, the community git server (git.postgresql.org) will be migrated to a new server in the same datacenter. This does *not* affect the master git server for the project, just the anonymous mirror and those that run standalone projects on it, such as pgAdmin. When this move is

Re: [HACKERS] Changing extension schema fails silently

2011-07-05 Thread Peter Geoghegan
From the docs: Note that unlike most catalogs with a "namespace" column, extnamespace is not meant to imply that the extension belongs to that schema. Extension names are never schema-qualified. Rather, extnamespace indicates the schema that contains most or all of the extension's objects. If extr

Re: [HACKERS] Changing extension schema fails silently

2011-07-05 Thread Thom Brown
On 5 July 2011 21:27, Thom Brown wrote: > Hi, > > I'm using the latest head and I created the file_fdw extension, then > attempted to change its schema (ALTER EXTENSION file_fdw SET SCHEMA > new_schema.  No error was returned, but it remained in the same schema > (according to pg_extension). > > I

Re: [HACKERS] SSI 2PC coverage

2011-07-05 Thread Dan Ports
On Tue, Jul 05, 2011 at 09:14:30PM +0300, Heikki Linnakangas wrote: > I think that needs some explanation, why only those SxactIsCommitted() > tests need to be replaced with SxactIsPrepared()? Here is the specific problem this patch addresses: If there's a dangerous structure T0 ---> T1 ---> T2,

[HACKERS] Changing extension schema fails silently

2011-07-05 Thread Thom Brown
Hi, I'm using the latest head and I created the file_fdw extension, then attempted to change its schema (ALTER EXTENSION file_fdw SET SCHEMA new_schema. No error was returned, but it remained in the same schema (according to pg_extension). I then dropped the extension and created it again specif

Re: [HACKERS] Small documentation issue

2011-07-05 Thread Tom Lane
Robert Haas writes: > On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz wrote: >> In fdwhandler.sgml, chapter fdwhandler has only one subsection >> (fdw-routines). >> >> If there is only one subsection, no table of contents is generated in >> the chapter. >> That means that people who navigate to the

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Dan Ports
On Tue, Jul 05, 2011 at 01:15:13PM -0500, Kevin Grittner wrote: > Heikki Linnakangas wrote: > > > Hmm, I think it would be simpler to decide that instead of > > SerializableXactHashLock, you must hold ProcArrayLock to access > > LastSxactCommitSeqNo, and move the assignment of commitSeqNo to

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Kevin Grittner
Tom Lane wrote: > Isn't SSI *already* forcing a new acquisition of an LWLock during > commits of read-only transactions that aren't using SSI? During COMMIT PREPARED there is one. We could avoid that by storing the transaction isolation level in the persistent data for a prepared statement, b

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Kevin Grittner
Robert Haas wrote: > On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner > wrote: >>> It'd be better to push some functionality into the procarray >>> code. >> >> That's easily done if we don't mind taking out a ProcArrayLock >> during completion of a transaction which has no XID, if only long >> enou

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Tom Lane
Robert Haas writes: > On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner > wrote: >> That's easily done if we don't mind taking out a ProcArrayLock >> during completion of a transaction which has no XID, if only long >> enough to increment a uint64 in shared memory, and then stash the >> value -- som

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner wrote: >> It'd be better to push some functionality into the procarray code. > > That's easily done if we don't mind taking out a ProcArrayLock > during completion of a transaction which has no XID, if only long > enough to increment a uint64 in share

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Tom Lane
I wrote: > I think it might be better to keep the convention that an empty options > list is represented by null, and to say that if a validator wants to be > called on such a list, it had better declare itself non-strict. At > least we ought to think about that before redefining the catalog > sem

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Kevin Grittner
Tom Lane wrote: > Heikki Linnakangas writes: >> Hmm, I think it would be simpler to decide that instead of >> SerializableXactHashLock, you must hold ProcArrayLock to access >> LastSxactCommitSeqNo, and move the assignment of commitSeqNo to >> ProcArrayTransaction(). It's probably easiest to m

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Tom Lane
Robert Haas writes: > 2011/7/1 Shigeru Hanada : >> I used ereport for the former check, because maybe such error usually >> happens and is visible to users.  This criteria was taken from the >> document "Reporting Errors Within the Server". >> http://developer.postgresql.org/pgdocs/postgres/error

Re: [HACKERS] %ENV warnings during builds

2011-07-05 Thread Brar Piening
Original Message Subject: Re: [HACKERS] %'ENV warnings during builds From: Andrew Dunstan To: Brar Piening Date: 05.07.2011 17:25 Try attached instead. I can confirm that this version of pgflex.pl works as expected in my environment. Regards, Brar -- Sent via pgsql-

Re: [HACKERS] SSI 2PC coverage

2011-07-05 Thread Kevin Grittner
Heikki Linnakangas wrote: >> Attached is also a patch to fix those, so that all permutations >> work. > > I think that needs some explanation, why only those > SxactIsCommitted() tests need to be replaced with > SxactIsPrepared()? What about the first SxactIsCommitted() test in > OnConflict_Che

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Tom Lane
Heikki Linnakangas writes: > Hmm, I think it would be simpler to decide that instead of > SerializableXactHashLock, you must hold ProcArrayLock to access > LastSxactCommitSeqNo, and move the assignment of commitSeqNo to > ProcArrayTransaction(). It's probably easiest to move > LastSxactCommitS

Re: [HACKERS] Review of VS 2010 support patches

2011-07-05 Thread Brar Piening
Original Message Subject: Review of VS 2010 support patches From: Craig Ringer To: PG Hackers , Brar Piening Date: 05.07.2011 14:25 I haven't had any reply to my email to Brar, so there are a few details (like whether x64 builds were tested and how x64 required libraries we

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Kevin Grittner
Heikki Linnakangas wrote: > Hmm, I think it would be simpler to decide that instead of > SerializableXactHashLock, you must hold ProcArrayLock to access > LastSxactCommitSeqNo, and move the assignment of commitSeqNo to > ProcArrayTransaction(). It's probably easiest to move > LastSxactCommit

Re: [HACKERS] SSI 2PC coverage

2011-07-05 Thread Heikki Linnakangas
On 05.07.2011 20:06, Kevin Grittner wrote: [resending after gzip of test patch] In reviewing the recent fix to 2PC coverage in SSI, I found some cases which didn't seem to be covered. Dan bit the bullet and came up with an additional isolation test to rigorously cover all the permutations, to f

Re: [HACKERS] SSI atomic commit

2011-07-05 Thread Heikki Linnakangas
On 05.07.2011 20:03, Kevin Grittner wrote: In reviewing the 2PC changes mentioned in a separate post, both Dan and I realized that these were dependent on the assumption that SSI's commitSeqNo is assigned in the order in which the transactions became visible. There is a race condition such that

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011-07-05 Thread Alvaro Herrera
Excerpts from Kohei Kaigai's message of mar jul 05 11:46:06 -0400 2011: > > On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera > > wrote: > > > Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011: > > > > > >> Hmm, OK.  I guess what I'm not sure about is - how much should we > > >>

Re: [HACKERS] lazy vxid locks, v2

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas wrote: > Here is an updated version of the "lazy vxid locks" patch [1], which > applies over the latest "reduce the overhead of frequent table > locks"[2] patch. > > [1] https://commitfest.postgresql.org/action/patch_view?id=585 > [2] https://commitfest.

Re: [HACKERS] [v9.2] Fix leaky-view problem, part 1

2011-07-05 Thread Noah Misch
On Sun, Jul 03, 2011 at 11:33:38AM +0200, Kohei KaiGai wrote: > The attached patches are revised version. > > The part-0 provides 'security_barrier' option for view definition, and > performs > as a common basis of part-1 and part-2 patches. > Syntax is extended as follows: > > CREATE VIEW vie

Re: [HACKERS] beta3?

2011-07-05 Thread Kevin Grittner
Robert Haas wrote: > Any other reason we can't or shouldn't wrap on the 11th? There are two new SSI issues which Dan and I spent a lot of time on over the holiday weekend. I hope they can be pushed before the 11th. I have added them to the Wiki page. -Kevin -- Sent via pgsql-hackers mai

[HACKERS] lazy vxid locks, v2

2011-07-05 Thread Robert Haas
Here is an updated version of the "lazy vxid locks" patch [1], which applies over the latest "reduce the overhead of frequent table locks"[2] patch. [1] https://commitfest.postgresql.org/action/patch_view?id=585 [2] https://commitfest.postgresql.org/action/patch_view?id=572 -- Robert Haas Enterp

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis wrote: > On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote: >> How about the idea of creating a family of four constructor functions >> for each new range type?  The functions would be named after the range >> type, with "_cc", "_co", "_oc", and "_oo"

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011-07-05 Thread Kohei Kaigai
> On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera > wrote: > > Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011: > > > >> Hmm, OK.  I guess what I'm not sure about is - how much should we > >> worry about the fact that this creates several more shared (and > >> therefore naile

[HACKERS] SSI atomic commit

2011-07-05 Thread Kevin Grittner
In reviewing the 2PC changes mentioned in a separate post, both Dan and I realized that these were dependent on the assumption that SSI's commitSeqNo is assigned in the order in which the transactions became visible. There is a race condition such that this is not necessarily true. It is a very n

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote: > How about the idea of creating a family of four constructor functions > for each new range type? The functions would be named after the range > type, with "_cc", "_co", "_oc", and "_oo" appended. So, then, instead > of writing: > > RANGE(1,

Re: [HACKERS] hint bit cache v6

2011-07-05 Thread Merlin Moncure
On Thu, Jun 30, 2011 at 3:42 PM, Merlin Moncure wrote: > On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas wrote: >> On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote: I think the basic problem is that the cache pages are so large.  It's hard to make them smaller because that increase

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-05 Thread Abel Abraham Camarillo Ojeda
Hi: On Tue, Jul 5, 2011 at 11:26 AM, Jeff Davis wrote: > In the 9.0 version of exclusion constraints, we added an extra check to > ensure that, when searching for a conflict, a tuple at least found > itself as a conflict. This extra check is not present in 9.1+. > > It was designed to help diagno

[HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-05 Thread Jeff Davis
In the 9.0 version of exclusion constraints, we added an extra check to ensure that, when searching for a conflict, a tuple at least found itself as a conflict. This extra check is not present in 9.1+. It was designed to help diagnose certain types of problems, and is fine for most use cases. A va

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure wrote: > On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas wrote: >> On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis wrote: >>> On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: > But if it's actually better, we should do it. If an intermediate typ

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Merlin Moncure
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas wrote: > On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis wrote: >> On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: >>> > But if it's actually better, we should do it. If an intermediate type >>> > seems to be problematic, or if people think it's stra

Re: [HACKERS] capturing regression test core dump

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 11:57 AM, Florian Pflug wrote: > On Jul5, 2011, at 17:49 , Robert Haas wrote: >> Is there any way to get the regression tests to write a core dump file >> somewhere that I can get at it?  I tried "ulimit -c unlimited" but >> can't find any core file lying around after I repr

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Pavel Golub
Hello, Robert. You wrote: RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote: >> RH> Yeah.  In particular, it conflicts with the ancient copy syntax which >> RH> we still support for backwards compatibility with versions < 7.3.  We >> RH> can fix the immediate problem with something like the

Re: [HACKERS] capturing regression test core dump

2011-07-05 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar jul 05 11:49:48 -0400 2011: > Is there any way to get the regression tests to write a core dump file > somewhere that I can get at it? I tried "ulimit -c unlimited" but > can't find any core file lying around after I reproduce the crash. Are you using a

Re: [HACKERS] Small SSI issues

2011-07-05 Thread Kevin Grittner
Robert Haas wrote: > Well, as long as we can verify that OLDSERXID_MAX_PAGE has the > same value for BLCKSZ=8K before and after this patch, I don't see > any real downside to applying it. If, hypothetically, it's buggy, > it's only going to break things for non-default block sizes which > are,

Re: [HACKERS] capturing regression test core dump

2011-07-05 Thread Florian Pflug
On Jul5, 2011, at 17:49 , Robert Haas wrote: > Is there any way to get the regression tests to write a core dump file > somewhere that I can get at it? I tried "ulimit -c unlimited" but > can't find any core file lying around after I reproduce the crash. In case you're on OSX, the core dumps ther

Re: [HACKERS] testing nested case-when scoping

2011-07-05 Thread Pavel Stehule
2011/7/5 Robert Haas : > On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule > wrote: >> Hello Heikki, >> >> probably I found a bug in patch: >> >> CREATE FUNCTION fx(i integer) RETURNS integer >>    LANGUAGE plpgsql >>    AS $$begin raise notice '>>%<<', i; return i; end;$$; >> >> CREATE FUNCTION fx1

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Tom Lane
Robert Haas writes: > ... However, if we don't do what I've proposed here, > then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as > they are, because... >> RH> (c) Should we consider removing compatibility with the ancient copy >> RH> syntax in 9.2, and de-reserving that keyword

[HACKERS] capturing regression test core dump

2011-07-05 Thread Robert Haas
Is there any way to get the regression tests to write a core dump file somewhere that I can get at it? I tried "ulimit -c unlimited" but can't find any core file lying around after I reproduce the crash. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Florian Pflug
On Jul5, 2011, at 17:11 , Jeff Davis wrote: > I'm OK with the intermediate type, but Florian seems skeptical of that > idea. I'm starting to get used to it, though ;-) I do now believe that it can be made safe against accidental miss-use, it seem that I was overly anxious there. What I still don'

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote: > RH> Yeah.  In particular, it conflicts with the ancient copy syntax which > RH> we still support for backwards compatibility with versions < 7.3.  We > RH> can fix the immediate problem with something like the attached. > > This patch is ugly.

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Pavel Golub
Hello, Robert. You wrote: RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera RH> wrote: >> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >>> Hello. >>> >>> System: PostgreSQL v9.0 Windows XP SP3 >>> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >>> ERROR:  syntax

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera >> wrote: >>> I assume it's not in unreserved_keyword because it would cause a >>> shift/reduce conflict elsewhere. > >> Yeah.  In particular, it conflicts with the ancient c

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Andrew Dunstan
On 07/05/2011 11:23 AM, Robert Haas wrote: Yeah. In particular, it conflicts with the ancient copy syntax which we still support for backwards compatibility with versions< 7.3. We can fix the immediate problem with something like the attached. (a) Should we do that? yes. (b) Should we

Re: [HACKERS] Core Extensions relocation

2011-07-05 Thread Robert Haas
On Sat, Jun 11, 2011 at 12:38 PM, Greg Smith wrote: > Peter Eisentraut wrote: >> For the directory name, I'd prefer either src/extensions (since there is >> more than one), or if you want to go for short somehow, src/ext.  (Hmm, >> I guess the installation subdirectory is also called "extension".

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Tom Lane
Robert Haas writes: > On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera > wrote: >> I assume it's not in unreserved_keyword because it would cause a >> shift/reduce conflict elsewhere. > Yeah. In particular, it conflicts with the ancient copy syntax which > we still support for backwards compatib

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis wrote: > On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: >> > But if it's actually better, we should do it. If an intermediate type >> > seems to be problematic, or if people think it's strange to require >> > casting, then I think this is reasonab

Re: [HACKERS] %ENV warnings during builds

2011-07-05 Thread Andrew Dunstan
On 07/05/2011 02:30 AM, Brar Piening wrote: schrieb Andrew Dunstan: Hmm, I missed that you had done this. Here are two replacement perl scripts I knocked up, but haven't yet tested. One of the things about them is that they remove knowledge of particular .l and .y files. and instead get the

Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera wrote: > Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >> Hello. >> >> System: PostgreSQL v9.0 Windows XP SP3 >> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >> ERROR:  syntax error at or near "binary" >> LINE 1: ...O

Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Pavel Golub
Hello, Alvaro. You wrote: AH> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >> Hello. >> >> System: PostgreSQL v9.0 Windows XP SP3 >> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >> ERROR: syntax error at or near "binary" >> LINE 1: ...OPY "tablename" TO STDOUT

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: > > But if it's actually better, we should do it. If an intermediate type > > seems to be problematic, or if people think it's strange to require > > casting, then I think this is reasonable. > > I don't understand how the bespoke syntax avoids

Re: [HACKERS] [COMMITTERS] pgsql: Move Trigger and TriggerDesc structs out of rel.h into a new rel

2011-07-05 Thread Tom Lane
Alvaro Herrera writes: > Excerpts from Tom Lane's message of mar jul 05 10:47:03 -0400 2011: >> I'm confused why this patch added pg_am.h to predtest.c? > ... > (Of course, the reason this didn't fail previously is because rel.h > includes pg_am.h). Oh, duh. Nevermind.

Re: [HACKERS] Small SSI issues

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 10:51 AM, Kevin Grittner wrote: >> Is this still an open item? > > Yes, although I'm not clear on whether people feel it is one which > needs to be fixed for 9.1 or left for 9.2. > > On a build with a BLCKSZ less than 8KB we would not get a warning > before problems occurred

Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Alvaro Herrera
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: > Hello. > > System: PostgreSQL v9.0 Windows XP SP3 > SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) > ERROR: syntax error at or near "binary" > LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) >

Re: [HACKERS] [COMMITTERS] pgsql: Move Trigger and TriggerDesc structs out of rel.h into a new rel

2011-07-05 Thread Alvaro Herrera
Excerpts from Tom Lane's message of mar jul 05 10:47:03 -0400 2011: > Alvaro Herrera writes: > > Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.h > > This lets us stop including rel.h into execnodes.h, which is a widely > > used header. > > I'm confused why this patch add

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011: > >> Hmm, OK.  I guess what I'm not sure about is - how much should we >> worry about the fact that this creates several more shared (and >> therefore nailed?) system cat

[HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"

2011-07-05 Thread Pavel Golub
Hello. System: PostgreSQL v9.0 Windows XP SP3 SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) ERROR: syntax error at or near "binary" LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) ^ ** Error ** ERROR: syntax erro

Re: [HACKERS] Small SSI issues

2011-07-05 Thread Kevin Grittner
Robert Haas wrote: > On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner > wrote: >> Heikki Linnakangas wrote: >> >>> * The oldserxid code is broken for non-default BLCKSZ. >>> o The warning will come either too early or too late >>> o There is no safeguard against actually wrapping around the >>> S

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011-07-05 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011: > Hmm, OK. I guess what I'm not sure about is - how much should we > worry about the fact that this creates several more shared (and > therefore nailed?) system catalogs? Anyone have an opinion on that? "Several"? That woul

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Albe Laurenz
Robert Haas wrote: I attached a patch which fixes file_fdw to check required option (filename) in its validator function.  I think that such requirement should be checked again in PlanForeignScan(), as it had been so far. Note that this patch requires fdw.patch has been applied.

Re: [HACKERS] [BUG] SSPI authentication fails on Windows when server parameter is localhost or domain name

2011-07-05 Thread Robert Haas
On Fri, Jun 17, 2011 at 6:32 AM, Thom Brown wrote: > On 15 June 2011 12:16, Dave Page wrote: >> On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari >> wrote: >>> Hi All, >>> >>> I faced a bug on Windows while connecting via SSPI authentication. I was >>> able to find the bug and have attached the p

Re: [HACKERS] testing nested case-when scoping

2011-07-05 Thread Robert Haas
On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule wrote: > Hello Heikki, > > probably I found a bug in patch: > > CREATE FUNCTION fx(i integer) RETURNS integer >    LANGUAGE plpgsql >    AS $$begin raise notice '>>%<<', i; return i; end;$$; > > CREATE FUNCTION fx1(integer) RETURNS text >    LANGUAGE

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011-07-05 Thread Robert Haas
On Mon, Jun 13, 2011 at 2:33 PM, Kohei KaiGai wrote: > 2011/6/13 Robert Haas : >> On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote: >>> 2011/6/13 Robert Haas : On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote: > The attached patch is an update revision of security label support >

Re: [HACKERS] Small SSI issues

2011-07-05 Thread Robert Haas
On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner wrote: > Heikki Linnakangas wrote: > >> * The oldserxid code is broken for non-default BLCKSZ. >> o The warning will come either too early or too late >> o There is no safeguard against actually wrapping around the >> SLRU, just the warning >> o I'm

Re: [HACKERS] Libpq enhancement

2011-07-05 Thread Robert Haas
On Tue, Jun 21, 2011 at 3:55 PM, Merlin Moncure wrote: >> For update, it's a bit more complex - we don't have a "replace into" >> operator... > > Actually, we do. 9.1 supports data modifying CTE around which it's > possible to rig a perfectly reasonable upsert...barring that, you > could triviall

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Robert Haas
On Fri, Jul 1, 2011 at 2:09 AM, Jeff Davis wrote: > On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote: >> Well, arrays are containers, and we need two values to construct a range, > > What about empty ranges? What about infinite ranges? > > It seems quite a bit more awkward to shoehorn ranges

Re: [HACKERS] Bug in SQL/MED?

2011-07-05 Thread Robert Haas
2011/7/1 Shigeru Hanada : > 2011/6/30 Alvaro Herrera : >> Excerpts from 花田 茂's message of jue jun 30 06:00:23 -0400 2011: >> >>> I attached a patch which fixes file_fdw to check required option >>> (filename) in its validator function.  I think that such requirement >>> should be checked again in P

Re: [HACKERS] Small documentation issue

2011-07-05 Thread Robert Haas
On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz wrote: > In fdwhandler.sgml, chapter fdwhandler has only one subsection > (fdw-routines). > > If there is only one subsection, no table of contents is generated in > the chapter. > That means that people who navigate to the chapter from the main table >

Re: [HACKERS] beta3?

2011-07-05 Thread Robert Haas
On Fri, Jul 1, 2011 at 6:06 PM, Josh Berkus wrote: >> That sounds reasonable to me.  I'll be on vacation then, but (1) I'm >> not really involved in pushing the release out the door and (2) I >> should have Internet access if push comes to shove. > > We seem to still have some blockers ... I'm on

Re: [HACKERS] Crash dumps

2011-07-05 Thread Robert Haas
On Tue, Jul 5, 2011 at 9:05 AM, Magnus Hagander wrote: > On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote: >> On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura >> wrote: >>> I asked about crash reports becaus of at this time there was thread about >>> crashing in live system. >> >> Yeah, I though

[HACKERS] Re: [BUGS] BUG #6083: psql script line numbers incorrectly count \copy data

2011-07-05 Thread Robert Haas
On Mon, Jul 4, 2011 at 12:02 PM, Tom Lane wrote: > "Steve Haslam" writes: >> ... Apparently, the data read from \copy >> is incrementing the script line number counter? > > Yeah, so it is.  That is correct behavior for COPY FROM STDIN, > but not so much for copying from a separate file. > > The a

Re: [HACKERS] Crash dumps

2011-07-05 Thread Magnus Hagander
On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote: > On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura > wrote: >> I asked about crash reports becaus of at this time there was thread about >> crashing in live system. > > Yeah, I thought this was the result of that effort: > > commit dcb09b595f88a3b

Re: [HACKERS] Crash dumps

2011-07-05 Thread Robert Haas
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura wrote: > I asked about crash reports becaus of at this time there was thread about > crashing in live system. Yeah, I thought this was the result of that effort: commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f Author: Magnus Hagander Date: Sun

[HACKERS] Review of VS 2010 support patches

2011-07-05 Thread Craig Ringer
Hi all I've got through a review of the VS 2010 support patches. Between work being busy and some interesting issues getting my 64-bit build environment set up it took longer than anticipated. Sorry. It looks good so far. I haven't had any reply to my email to Brar, so there are a few detail

Re: [HACKERS] Parameterized aggregate subquery (was: Pull up aggregate subquery)

2011-07-05 Thread Hitoshi Harada
2011/7/5 Yeb Havinga : > Hello Hitosh, list, > >> > >> > Attached is revised version. >> >> I failed to attached the patch. I'm trying again. >> > I'm currently unable to test, since on holiday. I'm happy to continue > testing once returned but it may not be within the bounds of the current > commi

Re: [HACKERS] Parameterized aggregate subquery (was: Pull up aggregate subquery)

2011-07-05 Thread Yeb Havinga
Hello Hitosh, list, > > > Attached is revised version. > > I failed to attached the patch. I'm trying again. > > I'm currently unable to test, since on holiday. I'm happy to continue testing once returned but it may not be within the bounds of the current commitfest, sorry. > >> 5) Regression te

Re: [HACKERS] Cascade replication

2011-07-05 Thread Simon Riggs
On Tue, Jul 5, 2011 at 4:34 AM, Fujii Masao wrote: > On Mon, Jul 4, 2011 at 6:24 PM, Simon Riggs wrote: >> On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao wrote: >> The standby must not accept replication connection from that standby itself. Otherwise, since any new WAL data would n

Re: [HACKERS] Inconsistency between postgresql.conf and docs

2011-07-05 Thread Fujii Masao
On Thu, Jun 30, 2011 at 1:34 AM, Josh Berkus wrote: > My preference would be to have: > > # REPLICATION > > # - Master Settings - > # these settings affect the master role in replication > # they will be ignored on the standby > > ... settings ... > > # - Standby Settings - > # these settings affe

Re: [HACKERS] Online base backup from the hot-standby

2011-07-05 Thread Fujii Masao
2011/7/5 Jun Ishiduka : > >> What about using backupStartPoint to check whether this recovery >> started from the backup or not? > > No, postgres can check whether this recovery started from the backup > or not, but can not check whether standby server or master (got backup > from). Oh, right. We

Re: [HACKERS] Latch implementation that wakes on postmaster death on both win32 and Unix

2011-07-05 Thread Peter Geoghegan
On 5 July 2011 07:49, Heikki Linnakangas wrote: > Good point, and testing shows that that is exactly what happens at least on > Linux (see attached test program). So, as the code stands, the children will > go into a busy loop until the grandparent calls waitpid(). That's not good. > > In that lig

Re: [HACKERS] Online base backup from the hot-standby

2011-07-05 Thread Jun Ishiduka
> What about using backupStartPoint to check whether this recovery > started from the backup or not? No, postgres can check whether this recovery started from the backup or not, but can not check whether standby server or master (got backup from). Once recovery started, backupStartPoint is rec

Re: [HACKERS] %ENV warnings during builds

2011-07-05 Thread Magnus Hagander
On Mon, Jul 4, 2011 at 23:30, Andrew Dunstan wrote: > > > On 07/03/2011 05:14 PM, Brar Piening wrote: >> >> schrieb Magnus Hagander: >>> >>> I think you've stumbled on just about all the bits of the MSVC build >>> system we haven't perlized. Maybe we should complete that task, and turn >>> clean.b