Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?

[Robert Haas]

On Tue, May 30, 2017 at 11:03 AM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Mon, May 29, 2017 at 3:04 AM, Tom Lane  wrote:
>>> Would someone please defend the restrictions imposed by the
>>> "seen_unbounded" checks in transformPartitionBound
>>> (parse_utilcmd.c:3365..3396 in current HEAD)?
>
>> Because this is supposed to work more or less like row-comparison --
>> the earlier columns are strictly more significant than the later ones.
>> That is, allowing (1, 2) through (3, 4) allows (2, whatever) but (1,
>> y) only if y >= 2 and (3, y) only if y < 4.
>
> I see.  That makes the logic awfully complex though.  I was looking
> at get_qual_for_range() yesterday --- it's mind-bendingly complicated
> and I have next to no faith that it's 100% right.

It might be useful if somebody would be willing to put together a
fuzz-tester for it.  Like, randomly generate partition bounds over
various different data types, and then verify that each tuple is
accepted by the partition constraint of only one partition and that
it's the same partition into which tuple routing tries to put it.

>> In case you're wondering, this is also how a certain large commercial
>> database system interprets composite bounds.  You could imagine in
>> theory a system where a bound from (1, 2) to (3, 4) allows only those
>> (x, y) where 1<=x<3 and 2<=y<4 but I know of no existing system that
>> does anything like that.  If you want that sort of thing, you can get
>> it anyway using two levels of partitioning, one on each column.
>
> Well, if we just treated each column independently, you could get
> the row-comparison behavior by partitioning on a ROW() expression.
> So that argument doesn't impress me.  I suppose compatibility with
> other partitioning implementations is worth something, but I'm not
> sure it's worth this much complication and risk of bugs.

I guess you won't be terribly surprised to hear that I think
compatibility with other implementations is quite desirable.  I also
think that Amit and others who have been involved in the discussions
have the same opinion, although of course they can speak for
themselves.  In terms of partitioning on a ROW() expression, I believe
that you would lose the ability to control which opclass and collation
is used for each column, which I think is something that people care
about.  Also, I bet it would be slower.  Also, I bet the syntax would
be less intuitive.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] "cannot specify finite value after UNBOUNDED" ... uh, why?

[Tom Lane]

Robert Haas  writes:
> On Mon, May 29, 2017 at 3:04 AM, Tom Lane  wrote:
>> Would someone please defend the restrictions imposed by the
>> "seen_unbounded" checks in transformPartitionBound
>> (parse_utilcmd.c:3365..3396 in current HEAD)?

> Because this is supposed to work more or less like row-comparison --
> the earlier columns are strictly more significant than the later ones.
> That is, allowing (1, 2) through (3, 4) allows (2, whatever) but (1,
> y) only if y >= 2 and (3, y) only if y < 4.

I see.  That makes the logic awfully complex though.  I was looking
at get_qual_for_range() yesterday --- it's mind-bendingly complicated
and I have next to no faith that it's 100% right.

> In case you're wondering, this is also how a certain large commercial
> database system interprets composite bounds.  You could imagine in
> theory a system where a bound from (1, 2) to (3, 4) allows only those
> (x, y) where 1<=x<3 and 2<=y<4 but I know of no existing system that
> does anything like that.  If you want that sort of thing, you can get
> it anyway using two levels of partitioning, one on each column.

Well, if we just treated each column independently, you could get
the row-comparison behavior by partitioning on a ROW() expression.
So that argument doesn't impress me.  I suppose compatibility with
other partitioning implementations is worth something, but I'm not
sure it's worth this much complication and risk of bugs.

regards, tom lane


-- 
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] "cannot specify finite value after UNBOUNDED" ... uh, why?

[Robert Haas]

On Mon, May 29, 2017 at 3:04 AM, Tom Lane  wrote:
> Would someone please defend the restrictions imposed by the
> "seen_unbounded" checks in transformPartitionBound
> (parse_utilcmd.c:3365..3396 in current HEAD)?  They sure look to me like
> nothing but sloppy thinking, and/or protection of downstream sloppy
> thinking.  Why should the boundedness of one partitioning column's
> range matter to any other partitioning column's range?

Because this is supposed to work more or less like row-comparison --
the earlier columns are strictly more significant than the later ones.
That is, allowing (1, 2) through (3, 4) allows (2, whatever) but (1,
y) only if y >= 2 and (3, y) only if y < 4.

In case you're wondering, this is also how a certain large commercial
database system interprets composite bounds.  You could imagine in
theory a system where a bound from (1, 2) to (3, 4) allows only those
(x, y) where 1<=x<3 and 2<=y<4 but I know of no existing system that
does anything like that.  If you want that sort of thing, you can get
it anyway using two levels of partitioning, one on each column.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] "cannot specify finite value after UNBOUNDED" ... uh, why?

[Amit Langote]

On 2017/05/29 16:04, Tom Lane wrote:
> Would someone please defend the restrictions imposed by the
> "seen_unbounded" checks in transformPartitionBound
> (parse_utilcmd.c:3365..3396 in current HEAD)?  They sure look to me like
> nothing but sloppy thinking, and/or protection of downstream sloppy
> thinking.  Why should the boundedness of one partitioning column's
> range matter to any other partitioning column's range?

If an earlier column's value is unbounded per the bound specification of a
range partition, later columns of an input row would never be compared
against their respective partition bounds, because the row's partition key
would trivially have been determined to be greater or less than the
partition's lower or upper bound, respectively, based on the comparison
against aforementioned unbounded column's infinite value.  Note that it's
the row comparison logic at work here.

Having said that, having finite values after an unbounded value doesn't
really affect tuple-routing code per se (which is what the above paragraph
is meant to describe the actions of), but it does affect the code that
creates constraint expression from the relpartbound value of a range
partition, at least because of the way get_qual_for_range() implements it.

If we had allowed them, an incorrect constraint expression would result as
illustrated below; consider a range partition:

create table foo (a int, b int) partition by range (a, b);
create table foo1 partition of foo for values in (unbounded, -1) to
(unbounded, 1);

foo1, as defined above, basically accepts any row with non-null a, if
inserted through foo via tuple-routing, because any non-null value of a is
trivially >= -infinity and < +infinity.

But, get_qual_for_range() would end up returning an expression that looks
like:

(b >= -1) and (b < 1)

which means that (2, 1) would fail to be inserted directly into foo1 due
to the above constraint, even if inserting it through foo would work,
because column b would not be considered in the latter.

Maybe there is a way to rewrite the code that generates the constraint
expression to somehow not emit the above expression, but any new code to
accomplish that might be more complicated than it is now.

See the following message:

https://www.postgresql.org/message-id/CA%2BTgmoYWnV2GMnYLG-Czsix-E1WGAbo4D%2B0tx7t9NdfYBDMFsA%40mail.gmail.com

I tend to agree with what Robert said there in the first part; there is no
point in allowing finite values to be specified after the last UNBOUNDED
in FROM and TO lists, which might mislead the user to believe that they
are actually significant.

Thanks,
Amit



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?

[Tom Lane]

Would someone please defend the restrictions imposed by the
"seen_unbounded" checks in transformPartitionBound
(parse_utilcmd.c:3365..3396 in current HEAD)?  They sure look to me like
nothing but sloppy thinking, and/or protection of downstream sloppy
thinking.  Why should the boundedness of one partitioning column's
range matter to any other partitioning column's range?

regards, tom lane


-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Wed, Mar 8, 2017 at 9:05 PM, Masahiko Sawada  wrote:
> On Wed, Feb 8, 2017 at 12:04 AM, Fujii Masao  wrote:
>> On Tue, Feb 7, 2017 at 2:13 AM, Petr Jelinek
>>  wrote:
>>> On 06/02/17 17:33, Fujii Masao wrote:
 On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
  wrote:
> On 03/02/17 19:38, Fujii Masao wrote:
>> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  
>> wrote:
>>> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>>>  wrote:
 At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
 wrote in 
 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Masahiko Sawada]

On Wed, Feb 8, 2017 at 12:04 AM, Fujii Masao  wrote:
> On Tue, Feb 7, 2017 at 2:13 AM, Petr Jelinek
>  wrote:
>> On 06/02/17 17:33, Fujii Masao wrote:
>>> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
>>>  wrote:
 On 03/02/17 19:38, Fujii Masao wrote:
> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  
> wrote:
>> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>>  wrote:
>>> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
>>> wrote in 
>>> 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Robert Haas]

On Sat, Feb 4, 2017 at 3:11 PM, Petr Jelinek
 wrote:
> That was the reason why DropSubscription didn't release the lock in the
> first place. It was supposed to be released at the end of the
> transaction though.

Holding an LWLock until end-of-transaction is a phenomenally bad idea,
both because you lose interruptibility and because of the deadlock
risk.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Tue, Feb 7, 2017 at 2:13 AM, Petr Jelinek
 wrote:
> On 06/02/17 17:33, Fujii Masao wrote:
>> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
>>  wrote:
>>> On 03/02/17 19:38, Fujii Masao wrote:
 On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  wrote:
> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>  wrote:
>> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
>> wrote in 
>> 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Petr Jelinek]

On 06/02/17 17:33, Fujii Masao wrote:
> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
>  wrote:
>> On 03/02/17 19:38, Fujii Masao wrote:
>>> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  wrote:
 On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
  wrote:
> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
> wrote in 
> 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
 wrote:
> On 03/02/17 19:38, Fujii Masao wrote:
>> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  wrote:
>>> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>>>  wrote:
 At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
 wrote in 
 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Petr Jelinek]

On 03/02/17 19:38, Fujii Masao wrote:
> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  wrote:
>> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>>  wrote:
>>> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  
>>> wrote in 
>>> 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao  wrote:
> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>  wrote:
>> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  wrote 
>> in 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
 wrote:
> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  wrote 
> in 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Kyotaro HORIGUCHI]

At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao  wrote in 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
 wrote:
> On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane  wrote:
>> Kyotaro HORIGUCHI  writes:
>>> Then, the reason for the TRY-CATCH cluase is that I found that
>>> some functions called from there can throw exceptions.
>>
>> Yes, but all LWLocks should be released by normal error recovery.
>> It should not be necessary for this code to clean that up by hand.
>> If it were necessary, there would be TRY-CATCH around every single
>> LWLockAcquire in the backend, and we'd have an unreadable and
>> unmaintainable system.  Please don't add a TRY-CATCH unless it's
>> *necessary* -- and you haven't explained why this one is.

Yes.

> Putting hands into the code and at the problem, I can see that
> dropping a subscription on a node makes it unresponsive in case of a
> stop. And that's just because calls to LWLockRelease are missing as in
> the patch attached. A try/catch problem should not be necessary.

Thanks for the patch!

With the patch, LogicalRepLauncherLock is released at the end of
DropSubscription(). But ISTM that the lock should be released just after
logicalrep_worker_stop() and there is no need to protect the removal of
replication slot with the lock.

/*
* If we found worker but it does not have proc set it is starting up,
* wait for it to finish and then kill it.
*/
while (worker && !worker->proc)
{

ISTM that the above loop in logicalrep_worker_stop() is not necessary
because LogicalRepLauncherLock ensures that the above condition is
always false. Thought? Am I missing something?

If the above condition is true, which means that there is the worker slot
having the "subid" of the worker to kill, but its "proc" has not been set yet.
Without LogicalRepLauncherLock, this situation can happen after "subid"
is set by the launcher and before "proc" is set by the worker. But
LogicalRepLauncherLock protects those operations, so logicalrep_worker_stop()
called while holding the lock should always think the above condition is false.

Regards,

-- 
Fujii Masao


-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Michael Paquier]

On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane  wrote:
> Kyotaro HORIGUCHI  writes:
>> Then, the reason for the TRY-CATCH cluase is that I found that
>> some functions called from there can throw exceptions.
>
> Yes, but all LWLocks should be released by normal error recovery.
> It should not be necessary for this code to clean that up by hand.
> If it were necessary, there would be TRY-CATCH around every single
> LWLockAcquire in the backend, and we'd have an unreadable and
> unmaintainable system.  Please don't add a TRY-CATCH unless it's
> *necessary* -- and you haven't explained why this one is.

Putting hands into the code and at the problem, I can see that
dropping a subscription on a node makes it unresponsive in case of a
stop. And that's just because calls to LWLockRelease are missing as in
the patch attached. A try/catch problem should not be necessary.
-- 
Michael


drop-subs-locks.patch
Description: Binary data

-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Tom Lane]

Kyotaro HORIGUCHI  writes:
> Then, the reason for the TRY-CATCH cluase is that I found that
> some functions called from there can throw exceptions.

Yes, but all LWLocks should be released by normal error recovery.
It should not be necessary for this code to clean that up by hand.
If it were necessary, there would be TRY-CATCH around every single
LWLockAcquire in the backend, and we'd have an unreadable and
unmaintainable system.  Please don't add a TRY-CATCH unless it's
*necessary* -- and you haven't explained why this one is.

regards, tom lane


-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Kyotaro HORIGUCHI]

At Thu, 2 Feb 2017 08:46:11 +0900, Michael Paquier  
wrote in 
> On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao  wrote:
> > The lwlock would be released when an exception occurs, so I don't think
> > that TRY-CATCH is necessary here. Or it's necessary for another reason?
> 
> +PG_CATCH();
> +{
> +LWLockRelease(LogicalRepLauncherLock);
> +PG_RE_THROW();
> +}
> +PG_END_TRY();
> Just to do that, a TRY/CATCH block looks like an overkill to me. Why
> not just call LWLockRelease in the ERROR and return code paths?

I though the same first. The modification at the "if (wrconn =="
is the remains of that. It is reverted inthe attached patch.

Then, the reason for the TRY-CATCH cluase is that I found that
some functions called from there can throw exceptions.

logicalrep_worker_stop and replorigin_drop have ereport in its path.
load_library apparently can throw exception.
(walrcv_(libpq_) functions don't seeem to.)

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
>From d0ca653bb2aa776742a2e7a697b02794b1ad66d9 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi 
Date: Thu, 2 Feb 2017 11:33:40 +0900
Subject: [PATCH] Fix DROP SUBSCRIPTION's lock leak.

DROP SUBSCRIPTION acquires a lock on LogicalRepLauncherLock but never
releases. This fixes it.
---
 src/backend/commands/subscriptioncmds.c | 86 ++---
 1 file changed, 48 insertions(+), 38 deletions(-)

diff --git a/src/backend/commands/subscriptioncmds.c b/src/backend/commands/subscriptioncmds.c
index 5de..223eea4 100644
--- a/src/backend/commands/subscriptioncmds.c
+++ b/src/backend/commands/subscriptioncmds.c
@@ -511,52 +511,62 @@ DropSubscription(DropSubscriptionStmt *stmt)
 	/* Protect against launcher restarting the worker. */
 	LWLockAcquire(LogicalRepLauncherLock, LW_EXCLUSIVE);
 
-	/* Kill the apply worker so that the slot becomes accessible. */
-	logicalrep_worker_stop(subid);
-
-	/* Remove the origin tracking if exists. */
-	snprintf(originname, sizeof(originname), "pg_%u", subid);
-	originid = replorigin_by_name(originname, true);
-	if (originid != InvalidRepOriginId)
-		replorigin_drop(originid);
-
-	/* If the user asked to not drop the slot, we are done mow.*/
-	if (!stmt->drop_slot)
-	{
-		heap_close(rel, NoLock);
-		return;
-	}
-
 	/*
-	 * Otherwise drop the replication slot at the publisher node using
-	 * the replication connection.
+	 * Some functions called here can throw exceptions. we must release
+	 * LogicalRepLauncherLock for the case.
 	 */
-	load_file("libpqwalreceiver", false);
+	PG_TRY();
+	{
+		/* Kill the apply worker so that the slot becomes accessible. */
+		logicalrep_worker_stop(subid);
 
-	initStringInfo();
-	appendStringInfo(, "DROP_REPLICATION_SLOT \"%s\"", slotname);
+		/* Remove the origin tracking if exists. */
+		snprintf(originname, sizeof(originname), "pg_%u", subid);
+		originid = replorigin_by_name(originname, true);
+		if (originid != InvalidRepOriginId)
+			replorigin_drop(originid);
 
-	wrconn = walrcv_connect(conninfo, true, subname, );
-	if (wrconn == NULL)
-		ereport(ERROR,
-(errmsg("could not connect to publisher when attempting to "
-		"drop the replication slot \"%s\"", slotname),
- errdetail("The error was: %s", err)));
+		/* Do the follwoing only if the user asked to actually drop the slot */
+		if (stmt->drop_slot)
+		{
+			/*
+			 * Drop the replication slot at the publisher node using the
+			 * replication connection.
+			 */
+			load_file("libpqwalreceiver", false);
 
-	if (!walrcv_command(wrconn, cmd.data, ))
-		ereport(ERROR,
-(errmsg("could not drop the replication slot \"%s\" on publisher",
-		slotname),
- errdetail("The error was: %s", err)));
-	else
-		ereport(NOTICE,
-(errmsg("dropped replication slot \"%s\" on publisher",
-		slotname)));
+			initStringInfo();
+			appendStringInfo(, "DROP_REPLICATION_SLOT \"%s\"", slotname);
+
+			wrconn = walrcv_connect(conninfo, true, subname, );
+			if (wrconn == NULL)
+ereport(ERROR,
+		(errmsg("could not connect to publisher when attempting to "
+"drop the replication slot \"%s\"", slotname),
+		 errdetail("The error was: %s", err)));
 
-	walrcv_disconnect(wrconn);
+			else if (!walrcv_command(wrconn, cmd.data, ))
+ereport(ERROR,
+		(errmsg("could not drop the replication slot \"%s\" on publisher",
+slotname),
+		 errdetail("The error was: %s", err)));
+
+			ereport(NOTICE,
+	(errmsg("dropped replication slot \"%s\" on publisher",
+			slotname)));
 
-	pfree(cmd.data);
+			walrcv_disconnect(wrconn);
+			pfree(cmd.data);
+		}
+	}
+	PG_CATCH();
+	{
+		LWLockRelease(LogicalRepLauncherLock);
+		PG_RE_THROW();
+	}
+	PG_END_TRY();
 
+	LWLockRelease(LogicalRepLauncherLock);
 	heap_close(rel, NoLock);
 }
 
-- 
2.9.2


-- 
Sent via pgsql-hackers mailing list 

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Michael Paquier]

On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao  wrote:
> The lwlock would be released when an exception occurs, so I don't think
> that TRY-CATCH is necessary here. Or it's necessary for another reason?

+PG_CATCH();
+{
+LWLockRelease(LogicalRepLauncherLock);
+PG_RE_THROW();
+}
+PG_END_TRY();
Just to do that, a TRY/CATCH block looks like an overkill to me. Why
not just call LWLockRelease in the ERROR and return code paths?
-- 
Michael


-- 
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] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Fujii Masao]

On Wed, Feb 1, 2017 at 5:36 PM, Kyotaro HORIGUCHI
 wrote:
> Hello, while looking another bug, I found that standby cannot
> shutdown after DROP SUBSCRIPTION.
>
> standby=# CREATE SUBSCRPTION sub1 ...
> standby=# 
> standby=# DROP SUBSCRIPTION sub1;
>
> Ctrl-C to the standby fails to work. ApplyLauncherMain is waiting
> LogicalRepLauncherLock forever.
>
> The culprit is DropSbuscription. It acquires
> LogicalRepLauncherLock but never releases.
>
> The attached patch fixes it. Most part of the fucntion is now
> enclosed by PG_TRY-CATCH since some functions can throw
> exceptions.

The lwlock would be released when an exception occurs, so I don't think
that TRY-CATCH is necessary here. Or it's necessary for another reason?

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

[Kyotaro HORIGUCHI]

Hello, while looking another bug, I found that standby cannot
shutdown after DROP SUBSCRIPTION.

standby=# CREATE SUBSCRPTION sub1 ...
standby=# 
standby=# DROP SUBSCRIPTION sub1;

Ctrl-C to the standby fails to work. ApplyLauncherMain is waiting
LogicalRepLauncherLock forever.

The culprit is DropSbuscription. It acquires
LogicalRepLauncherLock but never releases.

The attached patch fixes it. Most part of the fucntion is now
enclosed by PG_TRY-CATCH since some functions can throw
exceptions.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/commands/subscriptioncmds.c b/src/backend/commands/subscriptioncmds.c
index 5de..f07143e 100644
--- a/src/backend/commands/subscriptioncmds.c
+++ b/src/backend/commands/subscriptioncmds.c
@@ -511,51 +511,67 @@ DropSubscription(DropSubscriptionStmt *stmt)
 	/* Protect against launcher restarting the worker. */
 	LWLockAcquire(LogicalRepLauncherLock, LW_EXCLUSIVE);
 
-	/* Kill the apply worker so that the slot becomes accessible. */
-	logicalrep_worker_stop(subid);
-
-	/* Remove the origin tracking if exists. */
-	snprintf(originname, sizeof(originname), "pg_%u", subid);
-	originid = replorigin_by_name(originname, true);
-	if (originid != InvalidRepOriginId)
-		replorigin_drop(originid);
-
-	/* If the user asked to not drop the slot, we are done mow.*/
-	if (!stmt->drop_slot)
-	{
-		heap_close(rel, NoLock);
-		return;
-	}
-
 	/*
-	 * Otherwise drop the replication slot at the publisher node using
-	 * the replication connection.
+	 * replorigin_drop can throw an exception. we must release
+	 * LogicalRepLauncherLock for the case.
 	 */
-	load_file("libpqwalreceiver", false);
+	PG_TRY();
+	{
+		/* Kill the apply worker so that the slot becomes accessible. */
+		logicalrep_worker_stop(subid);
 
-	initStringInfo();
-	appendStringInfo(, "DROP_REPLICATION_SLOT \"%s\"", slotname);
+		/* Remove the origin tracking if exists. */
+		snprintf(originname, sizeof(originname), "pg_%u", subid);
+		originid = replorigin_by_name(originname, true);
+		if (originid != InvalidRepOriginId)
+			replorigin_drop(originid);
 
-	wrconn = walrcv_connect(conninfo, true, subname, );
-	if (wrconn == NULL)
-		ereport(ERROR,
-(errmsg("could not connect to publisher when attempting to "
-		"drop the replication slot \"%s\"", slotname),
- errdetail("The error was: %s", err)));
+		/* If the user asked to not drop the slot, we are done now.*/
+		if (stmt->drop_slot)
+		{
+			/*
+			 * Otherwise drop the replication slot at the publisher node using
+			 * the replication connection.
+			 */
+			load_file("libpqwalreceiver", false);
+
+			initStringInfo();
+			appendStringInfo(, "DROP_REPLICATION_SLOT \"%s\"", slotname);
+
+			wrconn = walrcv_connect(conninfo, true, subname, );
+			if (wrconn == NULL || !walrcv_command(wrconn, cmd.data, ))
+			{
+if (wrconn == NULL)
+	ereport(ERROR,
+			(errmsg("could not connect to publisher when "
+	"attempting to drop the "
+	"replication slot \"%s\"", slotname),
+			 errdetail("The error was: %s", err)));
 
-	if (!walrcv_command(wrconn, cmd.data, ))
-		ereport(ERROR,
-(errmsg("could not drop the replication slot \"%s\" on publisher",
-		slotname),
- errdetail("The error was: %s", err)));
-	else
-		ereport(NOTICE,
-(errmsg("dropped replication slot \"%s\" on publisher",
-		slotname)));
+ereport(ERROR,
+		(errmsg("could not drop the replication slot \"%s\" on publisher",
+slotname),
+		 errdetail("The error was: %s", err)));
+			}
 
-	walrcv_disconnect(wrconn);
+			ereport(NOTICE,
+	(errmsg("dropped replication slot \"%s\" on publisher",
+			slotname)));
 
-	pfree(cmd.data);
+			pfree(cmd.data);
+		}
+	}
+	PG_CATCH();
+	{
+		LWLockRelease(LogicalRepLauncherLock);
+		PG_RE_THROW();
+	}
+	PG_END_TRY();
+
+	LWLockRelease(LogicalRepLauncherLock);
+
+	if (wrconn)
+		walrcv_disconnect(wrconn);
 
 	heap_close(rel, NoLock);
 }

-- 
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] Cannot find a working 64-bit integer type

[Robert Haas]

On Sun, Jan 17, 2016 at 5:45 PM, Igal @ Lucee.org  wrote:
> UPDATE: when I ran: configure --without-zlib --enable-debug
> CFLAGS="-Wno-cpp"
>
> I did not get an error from configure (though I get an error from "make" but
> that's another issue)
>
> I'm not sure what I'm "losing" by passing the "no-cpp" compiler flag?

According to 'man gcc':

   -Wno-cpp
   (C, Objective-C, C++, Objective-C++ and Fortran only)

   Suppress warning messages emitted by "#warning" directives.

So apparently on your system configure fails the test for a 64-bit
integer type because a #warning is emitted, and compiling with
-Wno-cpp gets rid of that (probably without breaking anything else).
The relevant portion of config.log seems to be this:

configure:13285: gcc -o conftest.exe -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -O2
-I/home/Admin/sources/postgresql-9.5.0/src/include/port/win32
-DEXEC_BACKEND -Wl,--allow-multiple-definition
-Wl,--disable-auto-import conftest.c -lz -lws2_32 -lm >&5
conftest.c:106:5: warning: no previous prototype for 'does_int64_work'
[-Wmissing-prototypes] int does_int64_work()
conftest.c:120:1: warning: return type defaults to 'int' [-Wimplicit-int]
conftest.c: In function 'main':
conftest.c:121:3: warning: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
conftest.c:121:3: warning: incompatible implicit declaration of
built-in function 'exit'
conftest.c:121:3: note: include '' or provide a declaration of 'exit'
C:/Apps/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
reopening conftest.exe: Permission denied
C:/Apps/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
final link failed: Permission denied collect2.exe: error: ld returned
1 exit status
configure:13285: $? = 1 configure: program exited with status 1

I'm a little confused as to why -Wno-cpp fixes any of that, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] Cannot find a working 64-bit integer type

[Tom Lane]

Robert Haas  writes:
> The relevant portion of config.log seems to be this:

> configure:13285: gcc -o conftest.exe -Wall -Wmissing-prototypes
> -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -fexcess-precision=standard -O2
> -I/home/Admin/sources/postgresql-9.5.0/src/include/port/win32
> -DEXEC_BACKEND -Wl,--allow-multiple-definition
> -Wl,--disable-auto-import conftest.c -lz -lws2_32 -lm >&5
> conftest.c:106:5: warning: no previous prototype for 'does_int64_work'
> [-Wmissing-prototypes] int does_int64_work()
> conftest.c:120:1: warning: return type defaults to 'int' [-Wimplicit-int]
> conftest.c: In function 'main':
> conftest.c:121:3: warning: implicit declaration of function 'exit'
> [-Wimplicit-function-declaration]
> conftest.c:121:3: warning: incompatible implicit declaration of
> built-in function 'exit'
> conftest.c:121:3: note: include '' or provide a declaration of 
> 'exit'
> C:/Apps/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> reopening conftest.exe: Permission denied
> C:/Apps/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> final link failed: Permission denied collect2.exe: error: ld returned
> 1 exit status
> configure:13285: $? = 1 configure: program exited with status 1

I do not think configure pays attention to mere warnings for this type of
test.  The real problem here seems to be the "permission denied" errors,
which to me reek of broken Windows antivirus software.  (As far as I'm
aware, the word "broken" is redundant in that phrase.)

> I'm a little confused as to why -Wno-cpp fixes any of that, though.

Most likely, it's pure chance that a retry worked.  Or if it's repeatable,
maybe no-cpp changes the compiler's file access patterns enough that
there's no longer a false trip of the AV check.

Short answer is that I wonder how much of the OP's multiple problems
are being caused by AV bugs.

regards, tom lane


-- 
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] Cannot find a working 64-bit integer type

[Igal @ Lucee.org]

On 1/18/2016 11:09 AM, Tom Lane wrote:

Robert Haas  writes:

The relevant portion of config.log seems to be this:
I do not think configure pays attention to mere warnings for this type 
of test. The real problem here seems to be the "permission denied" 
errors, which to me reek of broken Windows antivirus software. (As far 
as I'm aware, the word "broken" is redundant in that phrase.)
Thank you both for looking into this.  The only A/V-type software that I 
have running is the "Microsoft Security Essentials".



I'm a little confused as to why -Wno-cpp fixes any of that, though.

Most likely, it's pure chance that a retry worked.  Or if it's repeatable,
maybe no-cpp changes the compiler's file access patterns enough that
there's no longer a false trip of the AV check.

Short answer is that I wonder how much of the OP's multiple problems
are being caused by AV bugs.
I did not make any changes other than adding the compiler flags between 
those two runs (nor afterwards).


The reason that I decided to try to add the -Wno-error flag was that I 
searched the net for the error message, and found this
thread from 4 years ago: 
http://postgresql.nabble.com/Setting-Werror-in-CFLAGS-td5118384.html -- 
which showed

a similar error message and a play of the compiler flags.

I will try to run both forms again and report whether it is repeatable.

Thanks again,


Igal



--
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] Cannot find a working 64-bit integer type

[Igal @ Lucee.org]

It looks like Tom is correct.

I added the directory tree to an exclude list of Microsoft Security 
Essentials and

ran `configure` without any flags and it completed successfully this time.

Thank you both for your time and expertise,


Igal

On 1/18/2016 11:23 AM, Igal @ Lucee.org wrote:

On 1/18/2016 11:09 AM, Tom Lane wrote:

Robert Haas  writes:

The relevant portion of config.log seems to be this:
I do not think configure pays attention to mere warnings for this 
type of test. The real problem here seems to be the "permission 
denied" errors, which to me reek of broken Windows antivirus 
software. (As far as I'm aware, the word "broken" is redundant in 
that phrase.)
Thank you both for looking into this.  The only A/V-type software that 
I have running is the "Microsoft Security Essentials".



I'm a little confused as to why -Wno-cpp fixes any of that, though.
Most likely, it's pure chance that a retry worked.  Or if it's 
repeatable,

maybe no-cpp changes the compiler's file access patterns enough that
there's no longer a false trip of the AV check.

Short answer is that I wonder how much of the OP's multiple problems
are being caused by AV bugs.
I did not make any changes other than adding the compiler flags 
between those two runs (nor afterwards).


The reason that I decided to try to add the -Wno-error flag was that I 
searched the net for the error message, and found this
thread from 4 years ago: 
http://postgresql.nabble.com/Setting-Werror-in-CFLAGS-td5118384.html 
-- which showed

a similar error message and a play of the compiler flags.

I will try to run both forms again and report whether it is repeatable.

Thanks again,


Igal





--
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] Cannot find a working 64-bit integer type

[Robert Haas]

On Mon, Jan 18, 2016 at 2:42 PM, Igal @ Lucee.org  wrote:
> It looks like Tom is correct.
>
> I added the directory tree to an exclude list of Microsoft Security
> Essentials and
> ran `configure` without any flags and it completed successfully this time.

Cool.

Man, Windows anti-virus software is a real nuisance.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] Cannot find a working 64-bit integer type

[Igal @ Lucee.org]

UPDATE: when I ran: configure --without-zlib --enable-debug 
CFLAGS="-Wno-cpp"


I did not get an error from configure (though I get an error from "make" 
but that's another issue)


I'm not sure what I'm "losing" by passing the "no-cpp" compiler flag?

also, the thread I mentioned in the previous email can be found at 
http://postgresql.nabble.com/Setting-Werror-in-CFLAGS-td5118384.html


Igal Sapir
Lucee Core Developer
Lucee.org 

On 1/17/2016 12:07 PM, Igal @ Lucee.org wrote:

Hi,

I'm trying to build Postgres with GCC 5.3.0 on Windows (a-la MinGW-64) 
and when I ran "configure" I received the following error:

"configure: error: Cannot find a working 64-bit integer type."

The config.log file can be seen at
https://gist.github.com/TwentyOneSolutions/8c225f66b9c0d4434871#file-config-201601171200-log-L21971

A google search finds this thread from 4 years ago, the IIUC explains 
that the issue is with newer GCC versions.


Any ideas on how I can overcome this issue?

Thanks!

--

Igal Sapir
Lucee Core Developer
Lucee.org 

[HACKERS] Cannot find a working 64-bit integer type

[Igal @ Lucee.org]

Hi,

I'm trying to build Postgres with GCC 5.3.0 on Windows (a-la MinGW-64) 
and when I ran "configure" I received the following error:

"configure: error: Cannot find a working 64-bit integer type."

The config.log file can be seen at
https://gist.github.com/TwentyOneSolutions/8c225f66b9c0d4434871#file-config-201601171200-log-L21971

A google search finds this thread from 4 years ago, the IIUC explains 
that the issue is with newer GCC versions.


Any ideas on how I can overcome this issue?

Thanks!

--

Igal Sapir
Lucee Core Developer
Lucee.org 

Re: [HACKERS] cannot set view triggers to replica

[Michael Paquier]

On Sat, May 30, 2015 at 11:47 AM, Peter Eisentraut pete...@gmx.net wrote:
 It appears to be an omission that ALTER TABLE ... ENABLE TRIGGER and
 similar commands don't allow acting on views, even though we now have
 triggers on views.

True, now isn't it something that should be as well part of ALTER VIEW?

 Similarly, the ALTER TABLE ... ENABLE RULE commands only allow acting on
 tables, even though rules can also exist on views and materialized views.

I think that ALTER VIEW and ALTER MATERIALIZED VIEW should be able to
accept the command as well.

 Attached is a sample patch.  It appears we don't have any regression
 tests for this.

This sounds like a mandatory condition for this patch.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] cannot set view triggers to replica

[Peter Eisentraut]

It appears to be an omission that ALTER TABLE ... ENABLE TRIGGER and
similar commands don't allow acting on views, even though we now have
triggers on views.

Similarly, the ALTER TABLE ... ENABLE RULE commands only allow acting on
tables, even though rules can also exist on views and materialized views.

(Why don't we allow rules on foreign tables?  Is that intentional?)

Attached is a sample patch.  It appears we don't have any regression
tests for this.
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 84dbee0..e530953 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -3341,13 +3341,18 @@ ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd *cmd,
 		case AT_DisableTrig:	/* DISABLE TRIGGER variants */
 		case AT_DisableTrigAll:
 		case AT_DisableTrigUser:
-			ATSimplePermissions(rel, ATT_TABLE | ATT_FOREIGN_TABLE);
+			ATSimplePermissions(rel, ATT_TABLE | ATT_FOREIGN_TABLE | ATT_VIEW);
 			pass = AT_PASS_MISC;
 			break;
 		case AT_EnableRule:		/* ENABLE/DISABLE RULE variants */
 		case AT_EnableAlwaysRule:
 		case AT_EnableReplicaRule:
 		case AT_DisableRule:
+			ATSimplePermissions(rel, ATT_TABLE | ATT_MATVIEW | ATT_VIEW);
+			/* These commands never recurse */
+			/* No command-specific prep needed */
+			pass = AT_PASS_MISC;
+			break;
 		case AT_AddOf:			/* OF */
 		case AT_DropOf: /* NOT OF */
 		case AT_EnableRowSecurity:

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] cannot to compile PL/V8 on Fedora 20

[Pavel Stehule]

Hello

I am trying to compile PL/v8 without success. I have Postgres installed via
compilation from source code.

After make I got errors

[pavel@localhost plv8-1.4.2]$ make
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8.o plv8.cc
plv8.cc:50:56: error: declaration of ‘Datum
plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
^
plv8.cc:43:7: error: from previous declaration ‘Datum
plv8_call_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plv8_call_handler);
   ^
plv8.cc:51:58: error: declaration of ‘Datum
plv8_call_validator(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plv8_call_validator(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:44:7: error: from previous declaration ‘Datum
plv8_call_validator(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plv8_call_validator);
   ^
plv8.cc:52:60: error: declaration of ‘Datum
plcoffee_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plcoffee_call_handler(PG_FUNCTION_ARGS) throw();
^
plv8.cc:45:7: error: from previous declaration ‘Datum
plcoffee_call_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plcoffee_call_handler);
   ^
plv8.cc:53:62: error: declaration of ‘Datum
plcoffee_call_validator(FunctionCallInfo) throw ()’ has a different
exception specifier
 Datum plcoffee_call_validator(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:46:7: error: from previous declaration ‘Datum
plcoffee_call_validator(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plcoffee_call_validator);
   ^
plv8.cc:54:56: error: declaration of ‘Datum
plls_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plls_call_handler(PG_FUNCTION_ARGS) throw();
^
plv8.cc:47:7: error: from previous declaration ‘Datum
plls_call_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plls_call_handler);
   ^
plv8.cc:55:58: error: declaration of ‘Datum
plls_call_validator(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plls_call_validator(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:48:7: error: from previous declaration ‘Datum
plls_call_validator(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plls_call_validator);
   ^
plv8.cc:63:58: error: declaration of ‘Datum
plv8_inline_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plv8_inline_handler(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:60:7: error: from previous declaration ‘Datum
plv8_inline_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plv8_inline_handler);
   ^
plv8.cc:64:62: error: declaration of ‘Datum
plcoffee_inline_handler(FunctionCallInfo) throw ()’ has a different
exception specifier
 Datum plcoffee_inline_handler(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:61:7: error: from previous declaration ‘Datum
plcoffee_inline_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plcoffee_inline_handler);
   ^
plv8.cc:65:58: error: declaration of ‘Datum
plls_inline_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 Datum plls_inline_handler(PG_FUNCTION_ARGS) throw();
  ^
plv8.cc:62:7: error: from previous declaration ‘Datum
plls_inline_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plls_inline_handler);
   ^
plv8.cc: In function ‘Datum plv8_call_handler(FunctionCallInfo)’:
plv8.cc:310:50: error: declaration of ‘Datum
plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 plv8_call_handler(PG_FUNCTION_ARGS) throw()
  ^
plv8.cc:50:7: error: from previous declaration ‘Datum
plv8_call_handler(FunctionCallInfo)’
 Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
   ^
plv8.cc: In function ‘Datum plcoffee_call_handler(FunctionCallInfo)’:
plv8.cc:316:54: error: declaration of ‘Datum
plcoffee_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 plcoffee_call_handler(PG_FUNCTION_ARGS) throw()
  ^
plv8.cc:52:7: error: from previous declaration ‘Datum
plcoffee_call_handler(FunctionCallInfo)’
 Datum plcoffee_call_handler(PG_FUNCTION_ARGS) throw();
   ^
plv8.cc: In function ‘Datum plls_call_handler(FunctionCallInfo)’:
plv8.cc:322:50: error: declaration of ‘Datum
plls_call_handler(FunctionCallInfo) throw ()’ has a different exception
specifier
 plls_call_handler(PG_FUNCTION_ARGS) throw()

Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

[Michael Paquier]

On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
 -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
 -fPIC -c -o plv8.o plv8.cc
 plv8.cc:50:56: error: declaration of 'Datum
 plv8_call_handler(FunctionCallInfo) throw ()' has a different exception
 specifier
  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
 Some ideas how to fix it?
It seems that you are compiling on the outdated branch staticlink. On
either master or r1.4 it will work properly on Fedora 20, at least it
works for me.
-- 
Michael


-- 
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] cannot to compile PL/V8 on Fedora 20

[Pavel Stehule]

2014-05-12 13:45 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:

 On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule pavel.steh...@gmail.com
 wrote:
  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
  -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
  -fPIC -c -o plv8.o plv8.cc
  plv8.cc:50:56: error: declaration of 'Datum
  plv8_call_handler(FunctionCallInfo) throw ()' has a different exception
  specifier
   Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
  Some ideas how to fix it?
 It seems that you are compiling on the outdated branch staticlink. On
 either master or r1.4 it will work properly on Fedora 20, at least it
 works for me.


How I can check it?

I had same bug with scientific linux and I expected so this problem will be
solved on new Fedora. On second computer on newer system I had same problem.

Some problem can be in my g++ environment - it is default Fedora.

Pavel


 --
 Michael

Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

[Andrew Dunstan]

On 05/12/2014 07:10 AM, Pavel Stehule wrote:

Hello

I am trying to compile PL/v8 without success. I have Postgres 
installed via compilation from source code.


After make I got errors

[pavel@localhost plv8-1.4.2]$ make
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server 
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE 
-I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
plv8.cc:50:56: error: declaration of ‘Datum 
plv8_call_handler(FunctionCallInfo) throw ()’ has a different 
exception specifier

 Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
^
plv8.cc:43:7: error: from previous declaration ‘Datum 
plv8_call_handler(FunctionCallInfo)’

 PG_FUNCTION_INFO_V1(plv8_call_handler);


This looks like a result of commit 
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4 
Maybe we need a way of telling the preprocessor to suppress the 
generation of a prototype?


cheers

andrew



--
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] cannot to compile PL/V8 on Fedora 20

[Pavel Stehule]

2014-05-12 15:42 GMT+02:00 Andrew Dunstan and...@dunslane.net:


 On 05/12/2014 07:10 AM, Pavel Stehule wrote:

 Hello

 I am trying to compile PL/v8 without success. I have Postgres installed
 via compilation from source code.

 After make I got errors

 [pavel@localhost plv8-1.4.2]$ make
 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
 -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
  -fPIC -c -o plv8.o plv8.cc
 plv8.cc:50:56: error: declaration of ‘Datum 
 plv8_call_handler(FunctionCallInfo)
 throw ()’ has a different exception specifier
  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
 ^
 plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler(
 FunctionCallInfo)’
  PG_FUNCTION_INFO_V1(plv8_call_handler);


 This looks like a result of commit http://git.postgresql.org/
 gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297
 e619bcbff4 Maybe we need a way of telling the preprocessor to suppress
 the generation of a prototype?


I got same result with tarball 9.2.4 released 2014-04-04

Pavel



 cheers

 andrew

Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 On 05/12/2014 07:10 AM, Pavel Stehule wrote:
 I am trying to compile PL/v8 without success. I have Postgres 
 installed via compilation from source code.

 plv8.cc:50:56: error: declaration of ‘Datum 
 plv8_call_handler(FunctionCallInfo) throw ()’ has a different 
 exception specifier
 Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
 ^
 plv8.cc:43:7: error: from previous declaration ‘Datum 
 plv8_call_handler(FunctionCallInfo)’
 PG_FUNCTION_INFO_V1(plv8_call_handler);

 This looks like a result of commit 
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4
  

Ouch.  I was a bit suspicious of that change from the start, but it hadn't
occurred to me that functions written in C++ would have an issue with it.

 Maybe we need a way of telling the preprocessor to suppress the 
 generation of a prototype?

Maybe we need to revert that patch altogether.  Dealing with this is
likely to introduce much more pain and confusion than the change is worth.

regards, tom lane


-- 
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] cannot to compile PL/V8 on Fedora 20

[Pavel Stehule]

2014-05-12 16:31 GMT+02:00 Tom Lane t...@sss.pgh.pa.us:

 Andrew Dunstan and...@dunslane.net writes:
  On 05/12/2014 07:10 AM, Pavel Stehule wrote:
  I am trying to compile PL/v8 without success. I have Postgres
  installed via compilation from source code.

  plv8.cc:50:56: error: declaration of ‘Datum
  plv8_call_handler(FunctionCallInfo) throw ()’ has a different
  exception specifier
  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
  ^
  plv8.cc:43:7: error: from previous declaration ‘Datum
  plv8_call_handler(FunctionCallInfo)’
  PG_FUNCTION_INFO_V1(plv8_call_handler);

  This looks like a result of commit
  
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4
 

 Ouch.  I was a bit suspicious of that change from the start, but it hadn't
 occurred to me that functions written in C++ would have an issue with it.

  Maybe we need a way of telling the preprocessor to suppress the
  generation of a prototype?

 Maybe we need to revert that patch altogether.  Dealing with this is
 likely to introduce much more pain and confusion than the change is worth.


After returning back before this commit I cannot compile PL/V8 still but
with more solvable bug

 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8.o plv8.cc
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8_type.o plv8_type.cc
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8_func.o plv8_func.cc
plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const
v8::Arguments)’:
plv8_func.cc:521:47: error: too few arguments to function ‘void
parseTypeString(const char*, Oid*, int32*, bool)’
   parseTypeString(typestr, types[i], typemod);
   ^
In file included from plv8_func.cc:22:0:
/usr/local/pgsql/include/server/parser/parse_type.h:50:13: note: declared
here
 extern void parseTypeString(const char *str, Oid *typeid_p, int32
*typmod_p, bool missing_ok);
 ^
make: *** [plv8_func.o] Error 1

so the main issue is really this commit

Regards

Pavel

p.s. my tests on 9.2 was messy probably






 regards, tom lane

Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

[Peter Eisentraut]

On 5/12/14, 11:05 AM, Pavel Stehule wrote:
 After returning back before this commit I cannot compile PL/V8 still but
 with more solvable bug
 
  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
 -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
 -I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
 -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
 -I/usr/include/libxml2  -fPIC -c -o plv8_type.o plv8_type.cc
 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
 -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
 -I/usr/include/libxml2  -fPIC -c -o plv8_func.o plv8_func.cc
 plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const
 v8::Arguments)’:
 plv8_func.cc:521:47: error: too few arguments to function ‘void
 parseTypeString(const char*, Oid*, int32*, bool)’
parseTypeString(typestr, types[i], typemod);
^
 In file included from plv8_func.cc:22:0:
 /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note:
 declared here
  extern void parseTypeString(const char *str, Oid *typeid_p, int32
 *typmod_p, bool missing_ok);
  ^
 make: *** [plv8_func.o] Error 1
 
 so the main issue is really this commit

You need plv8 master branch (unreleased), which fixes all these issues.
 No released version of plv8 works with 9.4 at the moment.


-- 
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] cannot to compile PL/V8 on Fedora 20

[Pavel Stehule]

2014-05-12 18:36 GMT+02:00 Peter Eisentraut pete...@gmx.net:

 On 5/12/14, 11:05 AM, Pavel Stehule wrote:
  After returning back before this commit I cannot compile PL/V8 still but
  with more solvable bug
 
   g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
  -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
  -I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
  -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
  -I/usr/include/libxml2  -fPIC -c -o plv8_type.o plv8_type.cc
  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
  -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
  -I/usr/include/libxml2  -fPIC -c -o plv8_func.o plv8_func.cc
  plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const
  v8::Arguments)’:
  plv8_func.cc:521:47: error: too few arguments to function ‘void
  parseTypeString(const char*, Oid*, int32*, bool)’
 parseTypeString(typestr, types[i], typemod);
 ^
  In file included from plv8_func.cc:22:0:
  /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note:
  declared here
   extern void parseTypeString(const char *str, Oid *typeid_p, int32
  *typmod_p, bool missing_ok);
   ^
  make: *** [plv8_func.o] Error 1
 
  so the main issue is really this commit

 You need plv8 master branch (unreleased), which fixes all these issues.
  No released version of plv8 works with 9.4 at the moment.


ok, I'll check it

Thank you

Pavel

Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

[Tom Lane]

Peter Eisentraut pete...@gmx.net writes:
 You need plv8 master branch (unreleased), which fixes all these issues.

How does it deal with the function declaration incompatibility problem?

regards, tom lane


-- 
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] cannot to compile PL/V8 on Fedora 20

[Peter Eisentraut]

On 5/12/14, 12:42 PM, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
 You need plv8 master branch (unreleased), which fixes all these issues.
 
 How does it deal with the function declaration incompatibility problem?

commit df92ced297282ffbb13e95748543b6c52ad4d238
Author: Hitoshi Harada umi.tan...@gmail.com
Date:   Wed May 7 01:28:18 2014 -0700

Remove exception specifier from PG callbacks.

9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is
not compatible with ours using exception specifiers.  Actually I don't
see the reason we have them so simply I remove them.


That said, I'm not yet sure what the overall right answer is here.



-- 
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] cannot to compile PL/V8 on Fedora 20

[Alvaro Herrera]

Peter Eisentraut wrote:
 On 5/12/14, 12:42 PM, Tom Lane wrote:
  Peter Eisentraut pete...@gmx.net writes:
  You need plv8 master branch (unreleased), which fixes all these issues.
  
  How does it deal with the function declaration incompatibility problem?
 
 commit df92ced297282ffbb13e95748543b6c52ad4d238
 Author: Hitoshi Harada umi.tan...@gmail.com
 Date:   Wed May 7 01:28:18 2014 -0700
 
 Remove exception specifier from PG callbacks.
 
 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is
 not compatible with ours using exception specifiers.  Actually I don't
 see the reason we have them so simply I remove them.

Do C++ exception specifiers in fmgr V1 functions work at all?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] cannot to compile PL/V8 on Fedora 20

[Tom Lane]

Peter Eisentraut pete...@gmx.net writes:
 On 5/12/14, 12:42 PM, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
 You need plv8 master branch (unreleased), which fixes all these issues.

 How does it deal with the function declaration incompatibility problem?

 commit df92ced297282ffbb13e95748543b6c52ad4d238
 Author: Hitoshi Harada umi.tan...@gmail.com
 Date:   Wed May 7 01:28:18 2014 -0700

 Remove exception specifier from PG callbacks.

 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is
 not compatible with ours using exception specifiers.  Actually I don't
 see the reason we have them so simply I remove them.

 That said, I'm not yet sure what the overall right answer is here.

Hm.  If you're writing SQL functions in C++, you definitely don't want
them throwing any C++ exceptions out to the core backend; so the throw()
declaration is sensible and might help catch coding errors.  That means
that Hitoshi-san's solution is just a quick hack rather than a desirable
answer.

We could perhaps use an #ifdef __cplusplus in the declaration of
PG_FUNCTION_INFO_V1 to forcibly put a throw() into the extern when
compiling C++.  That would break less-carefully-written C++ code, but
the fix would be easy (unless they are throwing exceptions, but then
they've got a bug to fix anyway).

I'm concerned though that this may not be the only use-case for
decorations on those externs.  A slightly more flexible answer
is to make it look like

#ifdef __cplusplus
#define PG_FUNCTION_DECORATION throw()
#else
#define PG_FUNCTION_DECORATION
#endif

#define PG_FUNCTION_INFO_V1(funcname) \
Datum funcname(PG_FUNCTION_ARGS) PG_FUNCTION_DECORATION; \
extern ...

which would leave the door open for modules to redefine
PG_FUNCTION_DECORATION if they had to.  On the other hand it could
reasonably be argued that that would largely break the point of
having a uniform extern declaration in the first place.

Still wondering if we shouldn't just revert this change as being more
pain than gain.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot allocate memory

[Heng Zhi Feng (zh...@hsr.ch)]

Hi,

We have a problem where PostgreSQL will restart or shutdown when calling it 
through PDAL write filter. This was after we applied pgtune on the 
postgresql.conf.

These are the settings on the machine:
Virtual Machine - Ubuntu 13.10
1.92GB Memory
2 Parallel Processors

And these are the configurations from pgtune:
#--
# CUSTOMIZED OPTIONS
#--
default_statistics_target = 50   # pgtune wizard 2013-11-14
maintenance_work_mem = 112MB   # pgtune wizard 2013-11-14
constraint_exclusion = on   # pgtune wizard 2013-11-14
checkpoint_completion_target = 0.9 # pgtune wizard 2013-11-14
effective_cache_size = 1408MB   # pgtune wizard 2013-11-14
work_mem = 11MB  # pgtune wizard 2013-11-14
wal_buffers = 8MB # pgtune wizard 
2013-11-14
checkpoint_segments = 16 # pgtune wizard 2013-11-14
shared_buffers = 448MB# pgtune wizard 2013-11-14
max_connections = 80  # pgtune wizard 2013-11-14

I have also set the shmmax to a higher value to adapt to the new configurations 
but it does not seem to solve the problem.

Below is a snippet of the postgresql.log:
2013-11-15 11:02:35 CET LOG:  could not fork autovacuum worker process: Cannot 
allocate memory
2013-11-15 11:02:36 CET LOG:  could not send data to client: Broken pipe
2013-11-15 11:02:36 CET LOG:  unexpected EOF on client connection

Thanks

Zhi Feng

Re: [HACKERS] Cannot allocate memory

[Kevin Grittner]

Heng Zhi Feng (zh...@hsr.ch) zh...@hsr.ch wrote:

 Virtual Machine – Ubuntu 13.10
 1.92GB Memory
 2 Parallel Processors

 work_mem = 11MB

 shared_buffers = 448MB
 max_connections = 80

 2013-11-15 11:02:35 CET LOG:  could not fork autovacuum worker process: 
 Cannot allocate memory
 2013-11-15 11:02:36 CET LOG:  could not send data to client: Broken pipe
 2013-11-15 11:02:36 CET LOG:  unexpected EOF on client connection

Before you start PostgreSQL, what does `free -m` show?

On such a tiny machine, some of the usual advice needs to be
modified a bit.  Sure, people say to start with shared_buffers at
25% of machine RAM, but if the (virtual) machine has so little RAM
that the OS is already taking a significant percentage, I would say
to go with 25% of what is free (excluding OS cache).  Likewise, the
advice I usually give to start with work_mem at 25% of machine RAM
divided by max_connections should be based on *available* RAM.  So
4MB to 5MB is probably going to be more appropriate than 11MB.  You
will probably need to reduce temp_buffers to 2MB or less -- right
now 1/3 of your machine RAM could be tied up in space reserved for
caching temporary table data, not released until connections close.

Since this VM is tight on resources and only has two cores, you
might want to use pgbouncer, configured in transaction mode with a
pool limited to something like 5 connections, so that you can
increase work_mem and avoid over-taxing the resources you have.

http://wiki.postgresql.org/wiki/Number_Of_Database_Connections

-- 
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] cannot move relocatable extension out of pg_catalog schema

[Hannu Krosing]

On 02/04/2013 02:16 AM, Robert Haas wrote:

On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut pete...@gmx.net wrote:

I wonder whether it'd not be a better idea to forbid specifying
pg_catalog as the target schema for relocatable extensions.

But that would be important, I think.

I understand the temptation to forbid pg_catalog as the target schema
for relocatable extensions, or indeed for object creation in general.
The fact that you can't, for example, go back and drop the objects
later is a real downer. On the other hand, from a user perspective,
it's really tempting to want to create certain extensions (adminpack,
for example) in such a way that they appear to be part of the system
rather than something that lives in a user schema.  Had we some other
solution to that problem (a second schema that behaves like pg_catalog
but is empty by default and allows drops?) we might alleviate the need
to put stuff in pg_catalog per se.

+1

Having a standard schema for extensions (say pg_extensions) is
something I have wanted multiple times.

Hannu





--
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] cannot move relocatable extension out of pg_catalog schema

[Dimitri Fontaine]

Robert Haas robertmh...@gmail.com writes:
 On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut pete...@gmx.net wrote:
 I wonder whether it'd not be a better idea to forbid specifying
 pg_catalog as the target schema for relocatable extensions.

We should do that, yes. Rationale: it's only documenting an existing
restriction that you just explained we can't get rid of. Want me to send
a patch (tomorrow)?

 I understand the temptation to forbid pg_catalog as the target schema
 for relocatable extensions, or indeed for object creation in general.

Those two cases are not to be mixed.

 The fact that you can't, for example, go back and drop the objects
 later is a real downer. On the other hand, from a user perspective,
 it's really tempting to want to create certain extensions (adminpack,
 for example) in such a way that they appear to be part of the system
 rather than something that lives in a user schema.  Had we some other

It's easy to do that in the extension's control properties:

relocatable = false
schema = pg_catalog

And the adminpack extension is already set that way. It's then part of
the system and you can still remove it. The only think you can not do is
move its objects in another schema, and I don't much see the point.

 solution to that problem (a second schema that behaves like pg_catalog
 but is empty by default and allows drops?) we might alleviate the need
 to put stuff in pg_catalog per se.

We had extensive talks about that when cooking the extension patch, and
that almost killed it. I think it took about a full year to get back on
our feet again. The only thing I know about that search_path can of
worms is that I will stay away from it as much as possible, and
wholeheartedly advice anyone to do the same.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support


-- 
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] cannot move relocatable extension out of pg_catalog schema

[Robert Haas]

On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut pete...@gmx.net wrote:
 I wonder whether it'd not be a better idea to forbid specifying
 pg_catalog as the target schema for relocatable extensions.

 But that would be important, I think.

I understand the temptation to forbid pg_catalog as the target schema
for relocatable extensions, or indeed for object creation in general.
The fact that you can't, for example, go back and drop the objects
later is a real downer. On the other hand, from a user perspective,
it's really tempting to want to create certain extensions (adminpack,
for example) in such a way that they appear to be part of the system
rather than something that lives in a user schema.  Had we some other
solution to that problem (a second schema that behaves like pg_catalog
but is empty by default and allows drops?) we might alleviate the need
to put stuff in pg_catalog per se.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] cannot move relocatable extension out of pg_catalog schema

[Peter Eisentraut]

create extension hstore with schema pg_catalog;
alter extension hstore set schema public;
ERROR:  0A000: cannot remove dependency on schema pg_catalog because it
is a system object
drop extension hstore;  -- works

I've seen this happen cleaning up after mistakenly misplaced extensions.
 I suspect this is a bug.


-- 
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] cannot move relocatable extension out of pg_catalog schema

[Tom Lane]

Peter Eisentraut pete...@gmx.net writes:
 create extension hstore with schema pg_catalog;
 alter extension hstore set schema public;
 ERROR:  0A000: cannot remove dependency on schema pg_catalog because it
 is a system object
 drop extension hstore;  -- works

 I've seen this happen cleaning up after mistakenly misplaced extensions.
  I suspect this is a bug.

It's not a bug, it's an intentional implementation restriction that
would be quite expensive to remove.

The reason it fails is that we don't record dependencies on system
objects, and therefore there's no way for ALTER EXTENSION to modify
those dependencies when trying to do SET SCHEMA.  That is, since
pg_catalog is pinned, we don't have any explicit record of which
objects in the extension would've needed dependencies on it, thus
no way to manufacture the dependencies on schema public that would
need to exist after the SET SCHEMA.

AFAICS the only maintainable fix would be to start storing dependencies
on pinned objects explicitly, which would make for enormous and 99.99%
useless bloat in pg_depend.

I wonder whether it'd not be a better idea to forbid specifying
pg_catalog as the target schema for relocatable extensions.

regards, tom lane


-- 
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] cannot move relocatable extension out of pg_catalog schema

[Peter Eisentraut]

On 2/1/13 3:21 PM, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
 create extension hstore with schema pg_catalog;
 alter extension hstore set schema public;
 ERROR:  0A000: cannot remove dependency on schema pg_catalog because it
 is a system object
 drop extension hstore;  -- works
 
 I've seen this happen cleaning up after mistakenly misplaced extensions.
  I suspect this is a bug.
 
 It's not a bug, it's an intentional implementation restriction that
 would be quite expensive to remove.
 
 The reason it fails is that we don't record dependencies on system
 objects, and therefore there's no way for ALTER EXTENSION to modify
 those dependencies when trying to do SET SCHEMA.  That is, since
 pg_catalog is pinned, we don't have any explicit record of which
 objects in the extension would've needed dependencies on it, thus
 no way to manufacture the dependencies on schema public that would
 need to exist after the SET SCHEMA.

Fair enough.  It's not that important.

 I wonder whether it'd not be a better idea to forbid specifying
 pg_catalog as the target schema for relocatable extensions.

But that would be important, I think.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] cannot disable hashSetOp

[Pavel Stehule]

hello

I looked on issue with consuming memory by query

HashSetOp Except  (cost=0.00..297100.69 rows=594044 width=30)
  -  Append  (cost=0.00..234950.32 rows=8286716 width=30)
-  Subquery Scan on *SELECT* 1  (cost=0.00..168074.62
rows=5940431 width=29)
  -  Seq Scan on ac  (cost=0.00..108670.31 rows=5940431 width=29)
-  Subquery Scan on *SELECT* 2  (cost=0.00..66875.70
rows=2346285 width=32)
  -  Seq Scan on artist_credit  (cost=0.00..43412.85
rows=2346285 width=32)


I was surprised, because I didn't find any way how to disable hashing.

Is there some way?

Pavel


-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Robert Haas]

On Sun, Dec 4, 2011 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Tomas Vondra t...@fuzzy.cz writes:
 What about the pg_stat_activity - is it safe to access that from auth
 hook or is that just a coincidence that it works (and might stop working
 in the future)?

 It doesn't seem like a good thing to rely on.  There's certainly no
 testing being done that would cause us to notice if it stopped working
 so early in backend startup.

I'm still puzzled that Tomas got it working at all.  If MyDatabaseId
hasn't been set yet, the how did we manage to build a relcache entry
for anything - let alone an unshared catalog?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tom Lane]

Robert Haas robertmh...@gmail.com writes:
 I'm still puzzled that Tomas got it working at all.  If MyDatabaseId
 hasn't been set yet, the how did we manage to build a relcache entry
 for anything - let alone an unshared catalog?

Well, he wasn't actually issuing a SQL query, just calling some of the
pgstat.c subroutines that underlie the view.  It happens that the pgstat
module has no backend-local initialization (at the moment, and
discounting the issue of making the process's own pgstat_activity entry),
so they were happy enough.  It was the syscache stuff that was spitting
up.

regards, tom lane

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Robert Haas]

On Mon, Dec 5, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 I'm still puzzled that Tomas got it working at all.  If MyDatabaseId
 hasn't been set yet, the how did we manage to build a relcache entry
 for anything - let alone an unshared catalog?

 Well, he wasn't actually issuing a SQL query, just calling some of the
 pgstat.c subroutines that underlie the view.  It happens that the pgstat
 module has no backend-local initialization (at the moment, and
 discounting the issue of making the process's own pgstat_activity entry),
 so they were happy enough.  It was the syscache stuff that was spitting
 up.

Oh, I see.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tomas Vondra]

On 4.12.2011 05:19, Tom Lane wrote:
 Tomas Vondra t...@fuzzy.cz writes:
 That might explain why it fails at first and then works just fine,
 although it's a bit strange. Wouldn't that mean you can't access any
 catalogs from the auth hook?
 
 It should be possible to access shared catalogs from an auth hook.
 pg_stat_activity is neither shared nor a catalog.  Like Robert,
 I find it astonishing that this works ever, because the info needed
 simply isn't available until you've connected to a particular database.
 The fact that the view is actually defined the same in every database
 doesn't enter into that ...

Hmmm, I do admit this is the first time I play with these things
(relcache, catalogs ...) so closely. so there are obviously things I'm
not aware of. For example I'm a bit confused what is / is not a shared
catalogue. Thanks in advance for your patience.

Anyway, the code I posted does not fail because of pg_stat_activity, it
fails because it attempts for find the dbname/username for the backends
(read from pg_stat_activity).

I've removed pg_stat_activity (see the code below) and it still fails.
The reason is that get_database_name attempts to read pg_database, but
once it gets to ScanPgRelation in relcache.c it notices MyDatabaseID=0
and so the check fails

This is the simplified code:

if (status == STATUS_OK)
{
char * db;

LWLockAcquire(lock, LW_EXCLUSIVE);

sleep(1);

if (MyBackendId  2) {
db = get_database_name(17000);
}

sleep(4);

LWLockRelease(lock);

}

If you start two backends at the same time, the first one gets ID=2 and
skips the get_database_name call, the second one gets ID=3 and calls the
function (and it fails). Subsequent calls work, because the first
backend initializes the relcache or something.

Tomas

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tom Lane]

Tomas Vondra t...@fuzzy.cz writes:
 On 4.12.2011 05:19, Tom Lane wrote:
 It should be possible to access shared catalogs from an auth hook.
 pg_stat_activity is neither shared nor a catalog.  Like Robert,
 I find it astonishing that this works ever, because the info needed
 simply isn't available until you've connected to a particular database.
 The fact that the view is actually defined the same in every database
 doesn't enter into that ...

 Hmmm, I do admit this is the first time I play with these things
 (relcache, catalogs ...) so closely. so there are obviously things I'm
 not aware of. For example I'm a bit confused what is / is not a shared
 catalogue. Thanks in advance for your patience.

See pg_class.relisshared.

 Anyway, the code I posted does not fail because of pg_stat_activity, it
 fails because it attempts for find the dbname/username for the backends
 (read from pg_stat_activity).

Well, get_database_name tries to do a syscache lookup, and the syscache
infrastructure isn't working yet.  It is possible to read a shared
catalog at this stage, but you have to use lower-level access mechanisms
--- for an example with some comments, look at GetDatabaseTuple in
postinit.c.

regards, tom lane

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tomas Vondra]

On 4.12.2011 17:10, Tom Lane wrote:
 Tomas Vondra t...@fuzzy.cz writes:
 Anyway, the code I posted does not fail because of pg_stat_activity, it
 fails because it attempts for find the dbname/username for the backends
 (read from pg_stat_activity).
 
 Well, get_database_name tries to do a syscache lookup, and the syscache
 infrastructure isn't working yet.  It is possible to read a shared
 catalog at this stage, but you have to use lower-level access mechanisms
 --- for an example with some comments, look at GetDatabaseTuple in
 postinit.c.

Great, this seems to work perfectly.

What about the pg_stat_activity - is it safe to access that from auth
hook or is that just a coincidence that it works (and might stop working
in the future)?

Tomas

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tom Lane]

Tomas Vondra t...@fuzzy.cz writes:
 What about the pg_stat_activity - is it safe to access that from auth
 hook or is that just a coincidence that it works (and might stop working
 in the future)?

It doesn't seem like a good thing to rely on.  There's certainly no
testing being done that would cause us to notice if it stopped working
so early in backend startup.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] cannot read pg_class without having selected a database / is this a bug?

[Tomas Vondra]

Hi,

I've written a simple extension that limits number of connection by
IP/db/user, and I do receive this exception:

psql: FATAL:  cannot read pg_class without having selected a database

I've found this happens because the extension defines a client auth hook
that reads pg_stat_activity. The really interesting thing is that this
happens only when I start several backends 'at the same time' right
after the cluster is started. From that time, everything works just fine.

So it seems like a race condition or something like that.

I've prepared a simple testcase to demonstrate this issue - see the
files attached. I've put there several 'sleep' to demonstrate the timing
error.

All you need to do is this:

1) compile the extension (make install)
2) add the extension to shared_preload_libraries
3) restart the cluster
4) start two backends at the same time (within a second or so)


Tomas
#include stdio.h
#include unistd.h

#include sys/time.h
#include sys/types.h
#include sys/ipc.h

#include postgres.h
#include miscadmin.h
#include storage/ipc.h

#include libpq/auth.h
#include pgstat.h

#include executor/executor.h
#include commands/dbcommands.h

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

/* allocates space for the rules */
static void pg_limits_shmem_startup(void);

/* check the rules (using pg_stat_activity) */
static void rules_check(Port *port, int status);

/* Saved hook values in case of unload */
static shmem_startup_hook_type prev_shmem_startup_hook = NULL;

/* Original Hook */
static ClientAuthentication_hook_type prev_client_auth_hook = NULL;

static LWLockId lock;

void		_PG_init(void);
void		_PG_fini(void);

/*
 * Module load callback
 */
void
_PG_init(void)
{
	
	/* can be preloaded only from postgresql.conf */
	if (! process_shared_preload_libraries_in_progress)
		elog(ERROR, connection_limits_shared has to be loaded using 
	shared_preload_libraries);
	
	/*
	 * Request additional shared resources.  (These are no-ops if we're not in
	 * the postmaster process.)  We'll allocate or attach to the shared
	 * resources in pg_limits_shmem_startup().
	 */
	RequestAddinLWLocks(1);

	/* Install hooks. */
	prev_shmem_startup_hook = shmem_startup_hook;
	shmem_startup_hook = pg_limits_shmem_startup;
	
	/* Install Hooks */
	prev_client_auth_hook = ClientAuthentication_hook;
	ClientAuthentication_hook = rules_check;

}

/*
 * Module unload callback
 */
void
_PG_fini(void)
{
	/* Uninstall hooks. */
	shmem_startup_hook = prev_shmem_startup_hook;
}

/* This is probably the most important part - allocates the shared 
 * segment, initializes it etc. */
static
void pg_limits_shmem_startup() {
	
	if (prev_shmem_startup_hook)
		prev_shmem_startup_hook();
	
	/*
	 * Create or attach to the shared memory state, including hash table
	 */
	LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE);
	
	/* First time through ... */
	lock = LWLockAssign();

	LWLockRelease(AddinShmemInitLock);
	
}

static
void rules_check(Port *port, int status)
{

	int b, nbackends;
	PgBackendStatus *beentry;

	/*
	 * Any other plugins which use ClientAuthentication_hook.
	 */
	if (prev_client_auth_hook)
		prev_client_auth_hook(port, status);

	/*
	 * Inject a short delay if authentication failed.
	 */
	if (status == STATUS_OK)
	{

		/* lock the segment (serializes the backend creation) */
		LWLockAcquire(lock, LW_EXCLUSIVE);
	
		sleep(1);
		
		/* how many backends are already there ? */
		nbackends = pgstat_fetch_stat_numbackends();
		
		/* loop through the backends */
		for (b = 1; b = nbackends; b++) {
			
			char * usr, * db;
			
			beentry = pgstat_fetch_stat_beentry(b);

			/* pgstatfuncs.c : 630 */
			if (beentry != NULL) {

db = get_database_name(beentry-st_databaseid);
usr = GetUserNameFromId(beentry-st_userid);

			} /* (beentry != NULL) */
			
		} /* for (b = 1; b = nbackends; b++) */

	}
	
	sleep(4);
	
	LWLockRelease(lock);

}
# issue
comment = '...'
default_version = '1.0.0'
relocatable = true

module_pathname = '$libdir/issue'MODULE_big = issue
OBJS = issue.o

EXTENSION = issue
MODULES = issue

CFLAGS=`pg_config --includedir-server`

PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

all: issue.so

issue.so: issue.o

issue.o : issue.c

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Robert Haas]

2011/12/3 Tomas Vondra t...@fuzzy.cz:
 psql: FATAL:  cannot read pg_class without having selected a database

 I've found this happens because the extension defines a client auth hook
 that reads pg_stat_activity. The really interesting thing is that this
 happens only when I start several backends 'at the same time' right
 after the cluster is started. From that time, everything works just fine.

I'm surprised this ever works.  To read pg_stat_activity, you need a
relcache entry for it.  And how will you build one without selecting a
database?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tomas Vondra]

On 3.12.2011 23:37, Robert Haas wrote:
 2011/12/3 Tomas Vondra t...@fuzzy.cz:
 psql: FATAL:  cannot read pg_class without having selected a database

 I've found this happens because the extension defines a client auth hook
 that reads pg_stat_activity. The really interesting thing is that this
 happens only when I start several backends 'at the same time' right
 after the cluster is started. From that time, everything works just fine.
 
 I'm surprised this ever works.  To read pg_stat_activity, you need a
 relcache entry for it.  And how will you build one without selecting a
 database?

What do you mean by selecting a database?

I do select a database when executing a psql, but I guess you mean
something that initializes the relcache entry and that's probably
executed after the auth hook.

That might explain why it fails at first and then works just fine,
although it's a bit strange. Wouldn't that mean you can't access any
catalogs from the auth hook?

Tomas

-- 
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] cannot read pg_class without having selected a database / is this a bug?

[Tom Lane]

Tomas Vondra t...@fuzzy.cz writes:
 That might explain why it fails at first and then works just fine,
 although it's a bit strange. Wouldn't that mean you can't access any
 catalogs from the auth hook?

It should be possible to access shared catalogs from an auth hook.
pg_stat_activity is neither shared nor a catalog.  Like Robert,
I find it astonishing that this works ever, because the info needed
simply isn't available until you've connected to a particular database.
The fact that the view is actually defined the same in every database
doesn't enter into that ...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot

[David E. Wheeler]

Suggested doc “patch”:

grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'

Best,

David


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

[Andrew Dunstan]

On 10/26/2011 02:16 PM, David E. Wheeler wrote:

Suggested doc “patch”:

 grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'




Why? can not is perfectly grammatical AFAIK.

cheers

andrew

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

[David E. Wheeler]

On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:

 Suggested doc “patch”:
 
 grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
 
 Why? can not is perfectly grammatical AFAIK.

True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:

para
  functionpg_advisory_xact_lock/ works the same as
  functionpg_advisory_lock/, expect the lock is automatically released
  at the end of the current transaction and can not be released explicitly.
 /para

I read this as equivalent to can be not released. Which of course is silly, 
so as I read it I realize what it means, but it trips up my overly logical 
brain. It interrupts the flow. There is no such confusion in cannot be 
released and thus no tripping up on meaning.

Best,

David
-- 
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] Cannot

[Andrew Dunstan]

On 10/26/2011 05:15 PM, David E. Wheeler wrote:

On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:


Suggested doc “patch”:

 grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'

Why? can not is perfectly grammatical AFAIK.

True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:


para
  functionpg_advisory_xact_lock/  works the same as
  functionpg_advisory_lock/, expect the lock is automatically released
  at the end of the current transaction and can not be released explicitly.
 /para

I read this as equivalent to can be not released. Which of course is silly, so as I 
read it I realize what it means, but it trips up my overly logical brain. It interrupts the flow. 
There is no such confusion in cannot be released and thus no tripping up on meaning.




Here's what I would do:

1. s/expect/except that/

2. s/can not be released explicitly/can not be explicitly released/

cheers

andrew


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

[Tom Lane]

David E. Wheeler da...@kineticode.com writes:
 On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:
 Why? can not is perfectly grammatical AFAIK.

 True, but there's a logic issue. Take this example from 
 doc/src/sgml/func.sgml:

 para
 functionpg_advisory_xact_lock/ works the same as
 functionpg_advisory_lock/, expect the lock is automatically released
 at the end of the current transaction and can not be released explicitly.
 /para

 I read this as equivalent to can be not released. Which of course is silly, 
 so as I read it I realize what it means, but it trips up my overly logical 
 brain. It interrupts the flow. There is no such confusion in cannot be 
 released and thus no tripping up on meaning.

This particular change seems like an improvement to me, but it's hardly
an adequate argument for a global search-and-replace.  There might be
other places where such a change renders things *less* readable.

regards, tom lane

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

[David E. Wheeler]

On Oct 26, 2011, at 2:58 PM, Tom Lane wrote:

 I read this as equivalent to can be not released. Which of course is 
 silly, so as I read it I realize what it means, but it trips up my overly 
 logical brain. It interrupts the flow. There is no such confusion in cannot 
 be released and thus no tripping up on meaning.
 
 This particular change seems like an improvement to me, but it's hardly
 an adequate argument for a global search-and-replace.  There might be
 other places where such a change renders things *less* readable.

The patch is actually quite modest; there are only a few instances of can 
not. Attached.

Best,

David



cannot.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot receive posts to pgsql-hackers through news server

[MauMau]

Hello,

I'm reading the posts of pgsql-hackers through the news server 
news.postgresql.org using Windows Mail on Windows Vista, to avoid receiving 
many emails. I don't seem to be able to receive posts in June. All I could 
download are before June. But I could receive messages in June of other MLs 
such as pgsql-general, pgsql-jdbc etc.


What could be wrong?

Regards
MauMau


--
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] Cannot build docs of 9.1 on Windows

[Andrew Dunstan]

On 05/19/2011 06:29 PM, MauMau wrote:

From: Andrew Dunstan and...@dunslane.net

On Thu, May 19, 2011 10:32 am, Robert Haas wrote:

2011/5/16 MauMau maumau...@gmail.com:

Can't open perl script make-errcodes-table.pl: No such file or
directory


I think this is the root of the problem.  We have no script called
make-errcodes-table.pl.  Can you try changing it to
generate-errcodes-table.pl and see if that works?




Building docs under Windows in the buildfarm is on my TODO list. We
already support it (as of a few weeks ago) for non-Windows build 
systems.


That will help us make sure we don't have this kind of drift.


Thank you. I could remove the error Can't open perl script 
make-errcodes-table.pl: N... by changing make-errcodes-table.pl 
to generate-errcodes-table.pl, but all other results seems to be 
same as before.


Andrew, could you announce the commit when you have successfully built 
docs on Windows? Can I know that fact by watching pgsql-hackers and 
pgsql-docs? I'll git-fetch the patch.





builddoc.bat failed on my system and reading it made my head hurt. So I 
did what I've done with other bat files and rewrote it in Perl. The 
result is attached. It works for me, and should be a dropin replacement. 
Just put it in the src/tools/msvc directory and run perl builddoc.pl. 
Please test it and if it works for you we'll use it and make 
builddoc.bat a thin wrapper like build.bat and vcregress.bat.


cheers

andrew


builddoc.pl
Description: Perl program

-- 
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] Cannot build docs of 9.1 on Windows

[MauMau]

Andrew,

From: Andrew Dunstan and...@dunslane.net

builddoc.bat failed on my system and reading it made my head hurt. So I
did what I've done with other bat files and rewrote it in Perl. The
result is attached. It works for me, and should be a dropin replacement.
Just put it in the src/tools/msvc directory and run perl builddoc.pl.
Please test it and if it works for you we'll use it and make
builddoc.bat a thin wrapper like build.bat and vcregress.bat.


It worked successfully! doc\src\sgml\html directory and its contents was 
created, and the HTML contents appear to be correct. Thank you very much. 
The output of perl builddoc.pl was as follows:



--
perl mk_feature_tables.pl YES 
../../../src/backend/catalog/sql_feature_packages.txt 
../../../src/backend/catalog/sql_features.txt  features-supported.sgmlperl 
mk_feature_tables.pl NO 
../../../src/backend/catalog/sql_feature_packages.txt 
../../../src/backend/catalog/sql_features.txt  features-unsupported.sgml
perl generate-errcodes-table.pl ../../../src/backend/utils/errcodes.txt  
errcodes-table.sgml

Running first build...
D:\pgdev\doctool/openjade-1.3.1/bin/openjade -V 
html-index -wall -wno-unused-param -wno-empty -D . -c 
D:\pgdev\doctool/docbook-dsssl-1.79/catalog -d stylesheet.dsl -i 
output-html -t sgml postgres.sgml 21 | findstr /V DTDDECL catalog entries 
are not supported

Running collateindex...
perl D:\pgdev\doctool/docbook-dsssl-1.79/bin/collateindex.pl -f -g -i 
bookindex -o bookindex.sgml HTML.index

Processing HTML.index...
2158 entries loaded...
0 entries ignored...
Done.
Running second build...
D:\pgdev\doctool/openjade-1.3.1/bin/openjade -wall -wno-unused-param -wno-empty 
-D . -c D:\pgdev\doctool/docbook-dsssl-1.79/catalog -d stylesheet.dsl -t 
sgml -i output-html -i include-index postgres.sgml 21 | findstr /V 
DTDDECL catalog entries are not supported

Docs build complete.
--


--
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] Cannot build docs of 9.1 on Windows

[Andrew Dunstan]

On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
 2011/5/16 MauMau maumau...@gmail.com:
 Can't open perl script make-errcodes-table.pl: No such file or
 directory

 I think this is the root of the problem.  We have no script called
 make-errcodes-table.pl.  Can you try changing it to
 generate-errcodes-table.pl and see if that works?



Building docs under Windows in the buildfarm is on my TODO list. We
already support it (as of a few weeks ago) for non-Windows build systems.

That will help us make sure we don't have this kind of drift.

cheers

andrew



-- 
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] Cannot build docs of 9.1 on Windows

[MauMau]

From: Andrew Dunstan and...@dunslane.net

On Thu, May 19, 2011 10:32 am, Robert Haas wrote:

2011/5/16 MauMau maumau...@gmail.com:

Can't open perl script make-errcodes-table.pl: No such file or
directory


I think this is the root of the problem.  We have no script called
make-errcodes-table.pl.  Can you try changing it to
generate-errcodes-table.pl and see if that works?




Building docs under Windows in the buildfarm is on my TODO list. We
already support it (as of a few weeks ago) for non-Windows build systems.

That will help us make sure we don't have this kind of drift.


Thank you. I could remove the error Can't open perl script 
make-errcodes-table.pl: N... by changing make-errcodes-table.pl to 
generate-errcodes-table.pl, but all other results seems to be same as 
before.


Andrew, could you announce the commit when you have successfully built docs 
on Windows? Can I know that fact by watching pgsql-hackers and pgsql-docs? 
I'll git-fetch the patch.


Regards
MauMau


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot build docs of 9.1 on Windows

[MauMau]

Hello,

I posted the following mail to pgsql-docs, but let me re-post it here 
because I'm afraid much less people watch pgsql-docs and pgsql-docs might be 
inactive. And the problem is not about the contents of docs but about the 
build system, so I thought here might be better.



I'm developing my first patch for PostgreSQL. The target is v9.2.

I'm trying to build HTML docs on Windows Vista (32-bit) with the latest v9.1
Git branch, but the build fails. I followed the procedures in the v9.0
manual. Could you tell me what might be the cause? The situation is as
follows:

The latest commit on my Git repository that git log -1 shows is:

--
commit 9bb6d9795253bb521f81c626fea49a704a369ca9
Author: Robert Haas rh...@postgresql.org
Date:   Fri May 13 15:47:31 2011 -0400

   More cleanup of FOREIGN TABLE permissions handling.
--

I could successfully build and install the program, do initdb, and
start/stop the PostgreSQL server.

The whole content of src/tools/msvc/buildenv.pl is:

$ENV{M4} = 'C:\GNUWin32\bin\m4.exe';
$ENV{DOCROOT} = 'D:\pgdev\doctool';

I ran builddoc.bat  out.txt 21 in src/tools/msvc. I expected to get
html directory in doc/src/sgml, but I couldn't get it after minutes of
execution. The output of builddoc.bat contains some errors. I'll show the
partial contents of out.txt below. The size of out.txt is too large (20.9MB)
to attach. out.txt appears to contain all the HTML manual.

--
Hash %ENV missing the % in argument 1 of each() at -e line 1.
Hash %ENV missing the % in argument 1 of each() at -e line 1.
Can't open perl script make-errcodes-table.pl: No such file or directory
Running first build...
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
HTML

HEAD
TITLE
PostgreSQL 9.1beta1 Documentation/TITLE
META

...

/BODY
/HTML


Running collateindex...
collateindex.pl: file HTML.index does not exist
Running second build...
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
HTML

HEAD
TITLE
PostgreSQL 9.1beta1 Documentation/TITLE
META

...

/BODY
/HTML





Docs build complete.
--

Regards,
MauMau


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Cannot *start* server because of a typo in pg_hba.conf

[Devrim GÜNDÜZ]

Yesterday I spent about half an hour to dig an issue on my laptop -- 9.0
instance did not start, and there were nothing in the logs. Eventually I
straced postmaster on start, and noticed an extra char in the
pg_hba.conf, which caused postmaster not to start.

Is it possible to drop something to (startup) log file and mention about
the syntax error in hba file?

(FWIW, I saw the same issue in a Greenplum 4.0.3 instance 2 months
before or so.)

-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Cannot *start* server because of a typo in pg_hba.conf

[Tom Lane]

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
 Yesterday I spent about half an hour to dig an issue on my laptop -- 9.0
 instance did not start, and there were nothing in the logs. Eventually I
 straced postmaster on start, and noticed an extra char in the
 pg_hba.conf, which caused postmaster not to start.

 Is it possible to drop something to (startup) log file and mention about
 the syntax error in hba file?

That information would certainly be logged somewhere.  Maybe you looked
in the wrong log file?  Or you're using one of those configurations
where early output to stderr goes to /dev/null?

regards, tom lane

-- 
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] Cannot *start* server because of a typo in pg_hba.conf

[Devrim GÜNDÜZ]

On Sun, 2011-02-20 at 10:39 -0500, Tom Lane wrote:
 
  Is it possible to drop something to (startup) log file and mention
  about the syntax error in hba file?
 
 That information would certainly be logged somewhere.  Maybe you
 looked in the wrong log file?  Or you're using one of those
 configurations where early output to stderr goes to /dev/null? 

I tried to start postmaster with:

* pg_ctl -D data start
* postmaster -D data
* pg_ctl -D data -l logfile start

None of them logged anything to anywhere. You can reproduce it on your
machine, too.
-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Cannot *start* server because of a typo in pg_hba.conf

[Tom Lane]

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
 On Sun, 2011-02-20 at 10:39 -0500, Tom Lane wrote:
 That information would certainly be logged somewhere.  Maybe you
 looked in the wrong log file?  Or you're using one of those
 configurations where early output to stderr goes to /dev/null? 

 None of them logged anything to anywhere. You can reproduce it on your
 machine, too.

No, I can't.  I get something like this on stderr:

LOG:  invalid connection type zlocal
CONTEXT:  line 82 of configuration file 
/home/postgres/testversion/data/pg_hba.conf
FATAL:  could not load pg_hba.conf

regards, tom lane

-- 
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] Cannot *start* server because of a typo in pg_hba.conf

[Devrim GÜNDÜZ]

On Sun, 2011-02-20 at 12:45 -0500, Tom Lane wrote:
 
  None of them logged anything to anywhere. You can reproduce it on
 your
  machine, too.
 
 No, I can't.  I get something like this on stderr:
 
 LOG:  invalid connection type zlocal 

Err, please try putting an extra char before the first comment line,
like:

w# PostgreSQL Client Authentication Configuration File

-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Cannot *start* server because of a typo in pg_hba.conf

[Thom Brown]

2011/2/20 Devrim GÜNDÜZ dev...@gunduz.org:
 On Sun, 2011-02-20 at 12:45 -0500, Tom Lane wrote:

  None of them logged anything to anywhere. You can reproduce it on
 your
  machine, too.

 No, I can't.  I get something like this on stderr:

 LOG:  invalid connection type zlocal

 Err, please try putting an extra char before the first comment line,
 like:

 w# PostgreSQL Client Authentication Configuration File

That mistake looks familiar ;)

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] Cannot *start* server because of a typo in pg_hba.conf

[Tom Lane]

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
 On Sun, 2011-02-20 at 12:45 -0500, Tom Lane wrote:
 No, I can't.  I get something like this on stderr:
 
 LOG:  invalid connection type zlocal 

 Err, please try putting an extra char before the first comment line,
 like:

 w# PostgreSQL Client Authentication Configuration File

Given exactly that mistake, I get

LOG:  invalid connection type w
CONTEXT:  line 1 of configuration file 
/home/postgres/testversion/data/pg_hba.conf
FATAL:  could not load pg_hba.conf

Are you sure you're looking in the right place?

One thought that comes to mind is that I've seen cases where SELinux
prevented the postmaster from writing anything at all to its stderr.
I didn't think that could still happen in any current SELinux versions,
but it might be worth checking the kernel log for avc denials.

regards, tom lane

-- 
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] Cannot compile Pg 9.0.2 with MinGW under Windows

[Pavel Golub]

Thanks, Andrew. I'll check my environment one more time.


You wrote:



AD On 12/23/2010 07:11 AM, Pavel Golub wrote:
 Hello, Pgsql-bugs.

 Tried to use MinGw under windows to build client libraries at least.
 However failed on ./configure --withou-zlib stage.

 Please find attached log file, stdout and stderr outputs.

 The main problem here I suppose is
 configure: WARNING:someheader.h: present but cannot be compiled

 Please five me advice on this.
 Thanks in advance


AD Your gcc doesn't look like others we have:

AD You have:

AD gcc (GCC) 3.4.4 (msys special)
AD Copyright (C) 2004 Free Software Foundation, Inc.
AD This is free software; see the source for copying conditions. There
AD is NO
AD warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
AD PURPOSE.

AD configure:3252: $? = 0
AD configure:3259: gcc -v 5
AD Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs
AD Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure
AD --prefix=/usr --sysconfdir=/etc --localstatedir=/var
AD --infodir=/share/info --mandir=/share/man --libexecdir=/lib
AD --enable-languages=c,c++ --disable-nls --enable-threads=posix
AD --enable-sjlj-exceptions --enable-hash-synchronization
AD --enable-libstdcxx-debug --with-newlib
AD Thread model: posix



AD Buildfarm narwhal has:

AD gcc.exe (GCC) 3.4.2 (mingw-special)
AD Copyright (C) 2004 Free Software Foundation, Inc.
AD This is free software; see the source for copying conditions. There is 
NO
AD warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

AD configure:3252: $? = 0
AD configure:3259: gcc -v5
AD Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
AD Configured with: ../gcc/configure --with-gcc --with-gnu-ld
AD --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
AD --enable-threads --disable-nls
AD --enable-languages=c,c++,f77,ada,objc,java
AD --disable-win32-registry --disable-shared --enable-sjlj-exceptions
AD --enable-libgcj --disable-java-awt --without-x
AD --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
AD --enable-hash-synchronization --enable-libstdcxx-debug
AD Thread model: win32
AD gcc version 3.4.2 (mingw-special)





AD Buildfarm frogmouth has:

AD gcc.exe (GCC) 4.5.0
AD Copyright (C) 2010 Free Software Foundation, Inc.
AD This is free software; see the source for copying conditions. There is 
NO
AD warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

AD configure:3252: $? = 0
AD configure:3259: gcc -v5
AD Using built-in specs.
AD COLLECT_GCC=c:\mingw\bin\gcc.exe
AD
AD 
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
AD Target: mingw32
AD Configured with: ../gcc-4.5.0/configure
AD --enable-languages=c,c++,ada,fortran,objc,obj-c++
AD --disable-sjlj-exceptions --with-dwarf2 --enable-shared
AD --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
AD --enable-version-specific-runtime-libs --disable-werror --build=mingw32 
--prefix=/mingw
AD Thread model: win32


AD gcc version 4.5.0 (GCC)




AD cheers

AD andrew



-- 
With best wishes,
 Pavel  mailto:pa...@gf.microolap.com


-- 
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] Cannot compile Pg 9.0.2 with MinGW under Windows

[Andrew Dunstan]

On 12/23/2010 07:11 AM, Pavel Golub wrote:

Hello, Pgsql-bugs.

Tried to use MinGw under windows to build client libraries at least.
However failed on ./configure --withou-zlib stage.

Please find attached log file, stdout and stderr outputs.

The main problem here I suppose is
configure: WARNING:someheader.h: present but cannot be compiled

Please five me advice on this.
Thanks in advance



Your gcc doesn't look like others we have:

You have:

   gcc (GCC) 3.4.4 (msys special)
   Copyright (C) 2004 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There
   is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
   PURPOSE.

   configure:3252: $? = 0
   configure:3259: gcc -v 5
   Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs
   Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure
   --prefix=/usr --sysconfdir=/etc --localstatedir=/var
   --infodir=/share/info --mandir=/share/man --libexecdir=/lib
   --enable-languages=c,c++ --disable-nls --enable-threads=posix
   --enable-sjlj-exceptions --enable-hash-synchronization
   --enable-libstdcxx-debug --with-newlib
   Thread model: posix



Buildfarm narwhal has:

   gcc.exe (GCC) 3.4.2 (mingw-special)
   Copyright (C) 2004 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

   configure:3252: $? = 0
   configure:3259: gcc -v5
   Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
   Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as 
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls 
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry 
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt 
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter 
--enable-hash-synchronization --enable-libstdcxx-debug
   Thread model: win32
   gcc version 3.4.2 (mingw-special)





Buildfarm frogmouth has:

   gcc.exe (GCC) 4.5.0
   Copyright (C) 2010 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

   configure:3252: $? = 0
   configure:3259: gcc -v5
   Using built-in specs.
   COLLECT_GCC=c:\mingw\bin\gcc.exe
   COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
   Target: mingw32
   Configured with: ../gcc-4.5.0/configure 
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions 
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry 
--enable-libstdcxx-debug --enable-version-specific-runtime-libs 
--disable-werror --build=mingw32 --prefix=/mingw
   Thread model: win32


   gcc version 4.5.0 (GCC)




cheers

andrew

--
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] Cannot cancel the change of a tablespace

[Guillaume Lelarge]

Le 30/06/2010 06:53, Guillaume Lelarge a écrit :
 Le 30/06/2010 05:25, Tom Lane a écrit :
 Robert Haas robertmh...@gmail.com writes:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 I tend to think we should fix it for 9.0, but could be talked out of
 it if someone has a compelling argument to make.

 Er, maybe I lost count, but I thought you were the one objecting to
 the patch.

 
 You're right. Robert questioned the use of CHECK_FOR_INTERRUPTS() in
 code available in the src/port directory. I don't see what issue could
 result with this. He also said that whatever would be commited should be
 back-patched.
 
 I can still add it for the next commit fest, I just don't want this
 patch to get lost. Though I won't be able to do this before getting back
 from work.
 

Finally, I added it to the next commit fest. Robert can work on it
before if he wants to (or has the time).

https://commitfest.postgresql.org/action/patch_view?id=331


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 Finally, I added it to the next commit fest. Robert can work on it
 before if he wants to (or has the time).

I'd been avoiding working on this because Simon had said he was going
to commit it, but I can pick it up.  I've committed and back-patched
(to 8.0, as 7.4 does not have tablespaces) the fix for ALTER TABLE ..
SET TABLESPACE.  I'll take a look at the rest of it as well.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 Finally, I added it to the next commit fest. Robert can work on it
 before if he wants to (or has the time).

 I'd been avoiding working on this because Simon had said he was going
 to commit it, but I can pick it up.  I've committed and back-patched
 (to 8.0, as 7.4 does not have tablespaces) the fix for ALTER TABLE ..
 SET TABLESPACE.  I'll take a look at the rest of it as well.

It looks like we have two reasonable choices here:

- We could backpatch this only to 8.4, where ALTER DATABASE .. SET
TABLESPACE was introduced.

- Or, since this also makes it easier to interrupt CREATE DATABASE new
TEMPLATE = some_big_database, we could back-patch it all the way to
8.1, which is the first release where we use copydir() rather than
invoking cp -r (except on Windows, where copydir() has always been
used, but releases  8.2 aren't supported on Windows anyway).

Since I can't remember anyone complaining about difficulty
interrupting CREATE DATABASE, I'm inclined to go back only to 8.4, and
will do that a bit later.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Guillaume Lelarge]

Le 01/07/2010 17:54, Robert Haas a écrit :
 On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 Finally, I added it to the next commit fest. Robert can work on it
 before if he wants to (or has the time).

 I'd been avoiding working on this because Simon had said he was going
 to commit it, but I can pick it up.  I've committed and back-patched
 (to 8.0, as 7.4 does not have tablespaces) the fix for ALTER TABLE ..
 SET TABLESPACE.  I'll take a look at the rest of it as well.
 
 It looks like we have two reasonable choices here:
 
 - We could backpatch this only to 8.4, where ALTER DATABASE .. SET
 TABLESPACE was introduced.
 
 - Or, since this also makes it easier to interrupt CREATE DATABASE new
 TEMPLATE = some_big_database, we could back-patch it all the way to
 8.1, which is the first release where we use copydir() rather than
 invoking cp -r (except on Windows, where copydir() has always been
 used, but releases  8.2 aren't supported on Windows anyway).
 
 Since I can't remember anyone complaining about difficulty
 interrupting CREATE DATABASE, I'm inclined to go back only to 8.4, and
 will do that a bit later.
 

I agree that a backpatch to 8.4 seems enough.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
 Le 01/07/2010 17:54, Robert Haas a écrit :
 On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 Finally, I added it to the next commit fest. Robert can work on it
 before if he wants to (or has the time).

 I'd been avoiding working on this because Simon had said he was going
 to commit it, but I can pick it up.  I've committed and back-patched
 (to 8.0, as 7.4 does not have tablespaces) the fix for ALTER TABLE ..
 SET TABLESPACE.  I'll take a look at the rest of it as well.

 It looks like we have two reasonable choices here:

 - We could backpatch this only to 8.4, where ALTER DATABASE .. SET
 TABLESPACE was introduced.

 - Or, since this also makes it easier to interrupt CREATE DATABASE new
 TEMPLATE = some_big_database, we could back-patch it all the way to
 8.1, which is the first release where we use copydir() rather than
 invoking cp -r (except on Windows, where copydir() has always been
 used, but releases  8.2 aren't supported on Windows anyway).

 Since I can't remember anyone complaining about difficulty
 interrupting CREATE DATABASE, I'm inclined to go back only to 8.4, and
 will do that a bit later.


 I agree that a backpatch to 8.4 seems enough.

Done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Guillaume Lelarge]

Le 01/07/2010 22:13, Robert Haas a écrit :
 On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 Le 01/07/2010 17:54, Robert Haas a écrit :
 On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us 
 wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 Finally, I added it to the next commit fest. Robert can work on it
 before if he wants to (or has the time).

 I'd been avoiding working on this because Simon had said he was going
 to commit it, but I can pick it up.  I've committed and back-patched
 (to 8.0, as 7.4 does not have tablespaces) the fix for ALTER TABLE ..
 SET TABLESPACE.  I'll take a look at the rest of it as well.

 It looks like we have two reasonable choices here:

 - We could backpatch this only to 8.4, where ALTER DATABASE .. SET
 TABLESPACE was introduced.

 - Or, since this also makes it easier to interrupt CREATE DATABASE new
 TEMPLATE = some_big_database, we could back-patch it all the way to
 8.1, which is the first release where we use copydir() rather than
 invoking cp -r (except on Windows, where copydir() has always been
 used, but releases  8.2 aren't supported on Windows anyway).

 Since I can't remember anyone complaining about difficulty
 interrupting CREATE DATABASE, I'm inclined to go back only to 8.4, and
 will do that a bit later.


 I agree that a backpatch to 8.4 seems enough.
 
 Done.
 

Thanks, Robert.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Tue, Jun 29, 2010 at 11:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 I tend to think we should fix it for 9.0, but could be talked out of
 it if someone has a compelling argument to make.

 Er, maybe I lost count, but I thought you were the one objecting to
 the patch.

No, I just wasn't sure whether it was safe.  If it's safe, I'm 100% in
favor of applying it and back-patching.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Guillaume Lelarge]

Le 23/06/2010 23:29, Guillaume Lelarge a écrit :
 Le 23/06/2010 22:54, Tom Lane a écrit :
 Robert Haas robertmh...@gmail.com writes:
 On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.

 Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
 ought to be OK (though I haven't tested), but copydir() is in
 src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
 might cause problems.

 copydir.c is already backend-specific thanks to all the ereport calls.
 If we ever tried to make it usable in frontend code, we could easily
 deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the
 error management would be far more painful.

 
 I'm not sure I get it right. Do I need to do something on the patch so
 that it can get commited?
 

Still not sure what to do right now for this patch :)

Could it be applied? or should I work on it? (and if yes on the latter,
to do what?)

Thanks.



-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
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] Cannot cancel the change of a tablespace

[Tom Lane]

Guillaume Lelarge guilla...@lelarge.info writes:
 Still not sure what to do right now for this patch :)

Put it on the commitfest list, if you didn't already.

regards, tom lane

-- 
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] Cannot cancel the change of a tablespace

[Bruce Momjian]

Tom Lane wrote:
 Guillaume Lelarge guilla...@lelarge.info writes:
  Still not sure what to do right now for this patch :)
 
 Put it on the commitfest list, if you didn't already.

So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see the patch on the commit-fest page yet.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + None of us is going to be here forever. +

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 Tom Lane wrote:
 Guillaume Lelarge guilla...@lelarge.info writes:
  Still not sure what to do right now for this patch :)

 Put it on the commitfest list, if you didn't already.

 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

I tend to think we should fix it for 9.0, but could be talked out of
it if someone has a compelling argument to make.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Tom Lane]

Robert Haas robertmh...@gmail.com writes:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.

 I tend to think we should fix it for 9.0, but could be talked out of
 it if someone has a compelling argument to make.

Er, maybe I lost count, but I thought you were the one objecting to
the patch.

regards, tom lane

-- 
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] Cannot cancel the change of a tablespace

[Guillaume Lelarge]

Le 30/06/2010 05:25, Tom Lane a écrit :
 Robert Haas robertmh...@gmail.com writes:
 On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
 So this is not something we want fixed for 9.0, as indicated by Simon?
 I don't see the patch on the commit-fest page yet.
 
 I tend to think we should fix it for 9.0, but could be talked out of
 it if someone has a compelling argument to make.
 
 Er, maybe I lost count, but I thought you were the one objecting to
 the patch.
 

You're right. Robert questioned the use of CHECK_FOR_INTERRUPTS() in
code available in the src/port directory. I don't see what issue could
result with this. He also said that whatever would be commited should be
back-patched.

I can still add it for the next commit fest, I just don't want this
patch to get lost. Though I won't be able to do this before getting back
from work.

Thanks.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
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] Cannot cancel the change of a tablespace

[Robert Haas]

On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
 Today, I tried to cancel the change of a tablespace for a table (ALTER
 TABLE ... SET TABLESPACE). I got the Cancel request sent but the query
 continued and finally succeed. It was a big issue for my customer, and I
 wanted to look more into that issue. So, I got a look at the source code
 and found we didn't check for interrupts in this part of the code. I
 added them, and it seems to work as I wanted.

 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.

 Not sure we really want that change, and it don't feel like a bug to me.
 Should I add it to to the next commitfest?

Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
ought to be OK (though I haven't tested), but copydir() is in
src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
might cause problems.

I think that whatever portion of this we end up applying should be back-patched.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

[Tom Lane]

Robert Haas robertmh...@gmail.com writes:
 On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.

 Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
 ought to be OK (though I haven't tested), but copydir() is in
 src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
 might cause problems.

copydir.c is already backend-specific thanks to all the ereport calls.
If we ever tried to make it usable in frontend code, we could easily
deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the
error management would be far more painful.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers