Re: [BUGS] BUG #6213: COPY does not work as expected in a plpgsql function
On Mon, Sep 26, 2011 at 12:45 AM, Ramanujam wrote: > On Mon, Sep 26, 2011 at 9:57 AM, Robert Haas wrote: >> Does it work if you use EXECUTE? > > Apologies to have not included the list when I replied to Pavel. > Re-writing it as a dynamic sql stmt indeed works. Sorry for the noise. Ah, OK. No problem. It would actually be nice if worked even without that, but I'm not sure what would be involved in making that happen. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6213: COPY does not work as expected in a plpgsql function
Robert Haas writes: > It would actually be nice if worked even without that, but I'm not > sure what would be involved in making that happen. I've been too busy to look at this in detail, but I imagine the issue is failure to pass parameters down from the ProcessUtility call to COPY into the parsing/execution of the sub-SELECT. It might be relatively straightforward to fix, or then again it might not. The parsing end of it could quite likely be harder than the execution end. We've surmounted similar issues in places like EXPLAIN, though. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6225: Child table with a missing parent key which no exists in a complex trigger/cascade schema
The following bug has been logged online:
Bug reference: 6225
Logged by: Daniel Cristian Cruz
Email address: danielcrist...@gmail.com
PostgreSQL version: 9.1.0
Operating system: "PostgreSQL 9.1.0 on x86_64-unknown-linux-gnu, compiled
by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit"
Description:Child table with a missing parent key which no exists in
a complex trigger/cascade schema
Details:
Hi masters,
I will update my server to 9.1.1, but saw right now it was updated, and I
know that this problem occurs in 9.0.4 because my team is using 9.0.
I had this schema, when, after deleting a main record, it cascades to
childrens.
The last line shows a repetition that has a repetition_conf that is no
longer in database...
CREATE TABLE event (
id_event serial primary key
);
CREATE TABLE repetition_conf (
id_repetition_conf serial primary key,
id_event integer,
CONSTRAINT event_fk FOREIGN KEY (id_event) REFERENCES event (id_event)
ON UPDATE NO ACTION ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED
-- IF MAIN EVENT IS DELETED, REPETITION CONFIG IS DELETED TOO
);
CREATE TABLE repetition (
id_repetition serial primary key,
id_repetition_conf integer,
id_event integer,
CONSTRAINT repetition_conf_fk FOREIGN KEY (id_repetition_conf) REFERENCES
repetition_conf (id_repetition_conf)
ON UPDATE NO ACTION ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
-- IF REPETITION CONFIG IS DELETED, REPETITION IS DELETED TOO
CONSTRAINT event_fk FOREIGN KEY (id_event) REFERENCES event (id_event)
ON UPDATE NO ACTION ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED
-- IF EVENT IS DELETED, SET NULL TO REFERENCE (BUSINESS LOGIC)
);
CREATE OR REPLACE FUNCTION remove_event()
RETURNS trigger AS
$BODY$
BEGIN
DELETE FROM event
WHERE id_event = OLD.id_event;
RETURN OLD;
END
$BODY$
LANGUAGE plpgsql VOLATILE;
CREATE TRIGGER remove_repetition_event
BEFORE DELETE
ON repetition
FOR EACH ROW
WHEN ((OLD.id_event IS NOT NULL))
EXECUTE PROCEDURE remove_event();
-- IF REPETITION IS DELETED, EVENT IS DELETED TOO
-- ACTUAL INSERT STEPS
BEGIN;
INSERT INTO event (id_event) VALUES (DEFAULT); -- CREATE MAIN EVENT
INSERT INTO repetition_conf (id_event) VALUES
(CURRVAL('event_id_event_seq')); -- CREATE REPETITION CONFIG
-- THESE TWO NEXT STEPS ARE A LOOP IN A TRIGGER ON repetition_conf
INSERT INTO event (id_event) VALUES (DEFAULT);
INSERT INTO repetition (id_repetition, id_repetition_conf, id_event)
VALUES (DEFAULT, CURRVAL('repetition_conf_id_repetition_conf_seq'),
CURRVAL('event_id_event_seq'));
COMMIT;
-- IN ANOTHER SESSION, DELETE THE MAIN EVENT, WICH WILL DELETE CONFIG AND
REPETITIONS
BEGIN;
DELETE FROM event WHERE id_event = 1;
COMMIT;
-- NOW I HAD A FOREIGN KEY WITH NO PARENT...
SELECT *
FROM repetition
LEFT JOIN repetition_conf
ON repetition.id_repetition_conf = repetition_conf.id_repetition_conf
WHERE repetition_conf.id_repetition_conf IS NULL;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Sun, Sep 25, 2011 at 9:16 PM, Fujii Masao wrote: > When I made pgbench tables unlogged and ran pgbench, I encountered a > segmentation fault. Here is the test case which reproduces a segmentation > fault: > > $ pgbench -i > $ pg_dump > pgbench.dump > $ sed s/"CREATE TABLE"/"CREATE UNLOGGED TABLE"/g pgbench.dump > > pgbench_unlogged.dump > $ createdb test > $ psql -f pgbench_unlogged.dump test > $ pgbench -c2 -T60 -Mprepared The first time I did this (on MacOS X), I got a bus error, just as you did. But I followed the exact series of commands above, which I believe would end up with the test running against the default database (with regular tables), rather than the test database with unlogged tables. The second time, it worked OK against the regular tables, so I then tried it again against the unlogged tables (by running the last command in the series again with "test" added to the end) and it then crashed with the following backtrace: #0 0x000101153560 in ?? () #1 0x0001001540fe in ExecScan (node=0x7fff5fbfde4f, accessMtd=0x100167150 , recheckMtd=0x100166ef0 ) at execScan.c:195 #2 0x00010014bcb2 in ExecProcNode (node=0x101151f30) at execProcnode.c:393 #3 0x000100164691 in ExecModifyTable (node=0x101151c20) at nodeModifyTable.c:766 #4 0x00010014bcf2 in ExecProcNode (node=0x101151c20) at execProcnode.c:370 #5 0x00010014a10e in ExecutePlan [inlined] () at /Users/rhaas/pgsql/src/backend/executor/execMain.c:1438 #6 0x00010014a10e in standard_ExecutorRun (queryDesc=0x10113f388, direction=ForwardScanDirection, count=0) at execMain.c:312 #7 0x00010023f714 in ProcessQuery (plan=0x101140e98, sourceText=0x10113f238 "UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2;", params=, dest=0x100520420, completionTag=0x7fff5fbfe450 "") at pquery.c:185 #8 0x00010023fe77 in PortalRunMulti (portal=0x10113d238, isTopLevel=, dest=0x100520420, altdest=0x100520420, completionTag=0x7fff5fbfe450 "") at pquery.c:1274 #9 0x000100240888 in PortalRun (portal=0x10113d238, count=9223372036854775807, isTopLevel=, dest=0x101055a50, altdest=0x101055a50, completionTag=0x7fff5fbfe450 "") at pquery.c:8& #11 0x0001001ee7ec in ServerLoop () at postmaster.c:3512 #12 0x0001001ef6d7 in PostmasterMain (argc=1, argv=0x100c08c40) at postmaster.c:1093 #13 0x0001001824b5 in main (argc=1, argv=0x100c08c40) at main.c:199 Unfortunately, this is thoroughly unhelpful, because the top of the stack has apparently been clobbered, and I can't see where inside ExecQual the crash is happening. (gdb) fr 1 #1 0x0001001540fe in ExecScan (node=0x7fff5fbfde4f, accessMtd=0x100167150 , recheckMtd=0x100166ef0 ) at execScan.c:195 195 if (!qual || ExecQual(qual, econtext, false)) The whole thing is a bit mysterious because ExecQual() doesn't really do much that seems like it could generate an invalid memory reference. I'll poke at this some more... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6223: Installation with service account
The following bug has been logged online: Bug reference: 6223 Logged by: Ola van Dunen Email address: vandu...@smart-interfaces.de PostgreSQL version: 9.* Operating system: Windows Server 2008 Description:Installation with service account Details: In order to run this database as a service under Windows Server 2008 R2 one is forced to install the active directory and to install the database at the same location of the to be installed domain controller which is basically an architectural bug to me. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( "!(owner->nsnapshots == 0)", File: "resowner.c", Line: 365)
hi,
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>>> There isn't terribly much we can do with this report unless you can
>>> provide a complete test case to reproduce it.
>
>> after some investigation, i think it is triggered by protocol-level prepare
>> of ROLLBACK in an aborted transaction. does the following patch make sense?
>
> Maybe, but I'd still like to see a test case, because I can't reproduce
> any such problem by preparing ROLLBACK in an aborted transaction.
reading GetTransactionSnapshot, it seems that the problem happens
only with IsolationUsesXactSnapshot() true.
the attached program triggers the assertion failure reliably for me.
YAMAMOTO Takashi
>
> regards, tom lane
#include
#include
#include
#include
int
main()
{
PGconn *conn;
PGresult *res;
conn = PQconnectdb("");
assert(PQstatus(conn) == CONNECTION_OK);
res = PQexec(conn, "SET SESSION CHARACTERISTICS AS "
"TRANSACTION ISOLATION LEVEL REPEATABLE READ");
assert(PQresultStatus(res) == PGRES_COMMAND_OK);
PQclear(res);
res = PQexec(conn, "BEGIN");
assert(PQresultStatus(res) == PGRES_COMMAND_OK);
PQclear(res);
res = PQexec(conn, "hoge"); /* intentional syntax error */
assert(PQresultStatus(res) != PGRES_COMMAND_OK);
PQclear(res);
assert(PQtransactionStatus(conn) == PQTRANS_INERROR);
res = PQprepare(conn, "r", "ROLLBACK", 0, NULL);
assert(PQresultStatus(res) == PGRES_COMMAND_OK);
PQclear(res);
res = PQexecPrepared(conn, "r", 0, NULL, NULL, NULL, 0);
assert(PQresultStatus(res) == PGRES_COMMAND_OK);
PQclear(res);
exit(0);
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6224: Installation Error of dotconnect for postgre SQL Professional
The following bug has been logged online: Bug reference: 6224 Logged by: Dean Heller Email address: dhel...@tainstruments.com PostgreSQL version: 4.95.170.0 Operating system: Windows 7 64bit Description:Installation Error of dotconnect for postgre SQL Professional Details: The following error is generated when installing the componet dotconnect for postgre SQL Professional on Windows 7 64bit OS --- Custom action error: CrGacUtil Date: 9/26/2011 6:34:19 AM Environment Operating System: Microsoft Windows NT 6.1.7600.0 .NET Framework: 2.0.50727.4927 Assembly: CrGacUtil, Version=1.0.0.0, Culture=neutral, PublicKeyToken=09af7300eec23701 Exception Message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Type: Devart.Common.Setup.CustomActionException StackTrace: at CrGacUtil.Program.Main(String[] args) CustomMessage: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Inner Exception Message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Type: Devart.Common.Setup.CustomActionException StackTrace: at CrGacUtil.Program.Main(String[] args) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] bug in plancache.c
hi,
GetCachedPlan can pass the 'qlist' to the planner twice.
if i understand the code correctly, it's unsafe because the planner is
destructive wrt the input tree. for my application, it often causes
a crash in executor.
YAMAMOTO Takashi
diff --git a/src/backend/utils/cache/plancache.c
b/src/backend/utils/cache/plancache.c
index cfeb824..78c2c31 100644
--- a/src/backend/utils/cache/plancache.c
+++ b/src/backend/utils/cache/plancache.c
@@ -949,6 +949,7 @@ GetCachedPlan(CachedPlanSource *plansource, ParamListInfo
boundParams,
{
/* Build a new generic plan */
plan = BuildCachedPlan(plansource, qlist, NULL);
+ qlist = NIL;
/* Just make real sure plansource->gplan is clear */
ReleaseGenericPlan(plansource);
/* Link the new generic plan into the plansource */
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6223: Installation with service account
On Mon, Sep 26, 2011 at 9:40 AM, Ola van Dunen wrote: > > The following bug has been logged online: > > Bug reference: 6223 > Logged by: Ola van Dunen > Email address: vandu...@smart-interfaces.de > PostgreSQL version: 9.* > Operating system: Windows Server 2008 > Description: Installation with service account > Details: > > In order to run this database as a service under > Windows Server 2008 R2 one is forced to install the active directory and to > install the database at the same location of the to be installed domain > controller which is basically an architectural bug to me. Whose packages are you using? That's certainly not the case with the EnterpriseDB installers. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Mon, Sep 26, 2011 at 11:00 AM, Robert Haas wrote:
> The whole thing is a bit mysterious because ExecQual() doesn't really
> do much that seems like it could generate an invalid memory reference.
>
> I'll poke at this some more...
I added some debugging code which sets a global variable to various
values as it executes this code. I was still able to reproduce the
crash (but only with unlogged tables, as in your original report) and
the crash appears to be happening here:
+ where_did_we_crash = 104;
expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
+ where_did_we_crash = 105;
I end up with where_did_we_crash = 104 in the core dump.
ExecEvalExpr is a macro which does this:
#define ExecEvalExpr(expr, econtext, isNull, isDone) \
((*(expr)->evalfunc) (expr, econtext, isNull, isDone))
I can't print out the value of "clause" directly, because the
invocation of ExecQual() doesn't even show up in the stack trace. But
I can see from the backtrace that it's getting called by ExecScan()
with an argument of qual. That qual is a one-element list, and it's
only element is also a List. That List contains a FuncExprState node
with an evalfunc of ExecEvalOper. But unless I'm missing something,
that's no good, because ExecQual is only walking the outer list, not
the inner one. And certainly if it tries to use a List object as an
ExprState, that's not going to work.
To check my work, I did this:
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bool
resultForNull)
Datum expr_value;
boolisNull;
+ Assert(!IsA(clause, List));
expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
if (isNull)
And in fact the test case (when run against the unlogged tables) fails
that assertion:
TRAP: FailedAssertion("!(!Node*)(clause))->type) == T_List))",
File: "execQual.c", Line: 5006)
Now I'm not too sure why that is happening yet, but I'm leaning toward
the idea that the bug here is timing-related and that unlogged tables
aren't the cause, but rather just make it easier to hit whatever the
race condition is by removing some overhead.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6224: Installation Error of dotconnect for postgre SQL Professional
On Mon, Sep 26, 2011 at 3:02 PM, Dean Heller wrote: > > The following bug has been logged online: > > Bug reference: 6224 > Logged by: Dean Heller > Email address: dhel...@tainstruments.com > PostgreSQL version: 4.95.170.0 > Operating system: Windows 7 64bit > Description: Installation Error of dotconnect for postgre SQL > Professional > Details: > > The following error is generated when installing the componet dotconnect for > postgre SQL Professional on Windows 7 64bit OS > > --- Custom action error: CrGacUtil > Date: 9/26/2011 6:34:19 AM > Environment > Operating System: Microsoft Windows NT 6.1.7600.0 > .NET Framework: 2.0.50727.4927 > Assembly: CrGacUtil, Version=1.0.0.0, Culture=neutral, > PublicKeyToken=09af7300eec23701 > Exception > Message: Access is denied. (Exception from HRESULT: 0x80070005 > (E_ACCESSDENIED)) > Type: Devart.Common.Setup.CustomActionException > StackTrace: at CrGacUtil.Program.Main(String[] args) > CustomMessage: Access is denied. (Exception from HRESULT: 0x80070005 > (E_ACCESSDENIED)) > Inner Exception > Message: Access is denied. (Exception from HRESULT: 0x80070005 > (E_ACCESSDENIED)) > Type: Devart.Common.Setup.CustomActionException > StackTrace: at CrGacUtil.Program.Main(String[] args) dotConnect isn't a project run by the PostgreSQL community, but a commercial product from Devart. You should report this issue to them. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Mon, Sep 26, 2011 at 11:40 AM, Robert Haas wrote:
> To check my work, I did this:
>
> --- a/src/backend/executor/execQual.c
> +++ b/src/backend/executor/execQual.c
> @@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bool
> resultForNull)
> Datum expr_value;
> bool isNull;
>
> + Assert(!IsA(clause, List));
> expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
>
> if (isNull)
>
> And in fact the test case (when run against the unlogged tables) fails
> that assertion:
>
> TRAP: FailedAssertion("!(!Node*)(clause))->type) == T_List))",
> File: "execQual.c", Line: 5006)
>
> Now I'm not too sure why that is happening yet, but I'm leaning toward
> the idea that the bug here is timing-related and that unlogged tables
> aren't the cause, but rather just make it easier to hit whatever the
> race condition is by removing some overhead.
I cannot reproduce this on commit
e6faf910d75027bdce7cd0f2033db4e912592bcc. But on the very next commit
I can:
commit e6faf910d75027bdce7cd0f2033db4e912592bcc
Author: Tom Lane
Date: Fri Sep 16 00:42:53 2011 -0400
Redesign the plancache mechanism for more flexibility and efficiency.
Tom, any thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Mon, Sep 26, 2011 at 11:08 AM, Robert Haas wrote:
> On Mon, Sep 26, 2011 at 11:40 AM, Robert Haas wrote:
>> To check my work, I did this:
>>
>> --- a/src/backend/executor/execQual.c
>> +++ b/src/backend/executor/execQual.c
>> @@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bool
>> resultForNull)
>> Datum expr_value;
>> bool isNull;
>>
>> + Assert(!IsA(clause, List));
>> expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
>>
>> if (isNull)
>>
>> And in fact the test case (when run against the unlogged tables) fails
>> that assertion:
>>
>> TRAP: FailedAssertion("!(!Node*)(clause))->type) == T_List))",
>> File: "execQual.c", Line: 5006)
>>
>> Now I'm not too sure why that is happening yet, but I'm leaning toward
>> the idea that the bug here is timing-related and that unlogged tables
>> aren't the cause, but rather just make it easier to hit whatever the
>> race condition is by removing some overhead.
>
> I cannot reproduce this on commit
> e6faf910d75027bdce7cd0f2033db4e912592bcc. But on the very next commit
> I can:
>
> commit e6faf910d75027bdce7cd0f2033db4e912592bcc
> Author: Tom Lane
> Date: Fri Sep 16 00:42:53 2011 -0400
>
> Redesign the plancache mechanism for more flexibility and efficiency.
>
> Tom, any thoughts?
hm. any relation to YAMAMOTO Takashi's recent email, [BUGS] bug in
plancache.c, which hasn't hit the archives yet?
> "GetCachedPlan can pass the 'qlist' to the planner twice.
if i understand the code correctly, it's unsafe because the planner is
destructive wrt the input tree. for my application, it often causes
a crash in executor."
merlin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Mon, Sep 26, 2011 at 12:17 PM, Merlin Moncure wrote: > hm. any relation to YAMAMOTO Takashi's recent email, [BUGS] bug in > plancache.c, which hasn't hit the archives yet? > >> "GetCachedPlan can pass the 'qlist' to the planner twice. > if i understand the code correctly, it's unsafe because the planner is > destructive wrt the input tree. for my application, it often causes > a crash in executor." I was just wondering about that. It seems like it could very well be the same issue, but I have not tested it yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( "!(owner->nsnapshots == 0)", File: "resowner.c", Line: 365)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: >> Maybe, but I'd still like to see a test case, because I can't reproduce >> any such problem by preparing ROLLBACK in an aborted transaction. > reading GetTransactionSnapshot, it seems that the problem happens > only with IsolationUsesXactSnapshot() true. Hmm. I'm inclined to think that this demonstrates a bug in snapshot management, not so much in plancache. We have plancache doing PushActiveSnapshot(GetTransactionSnapshot()); and then later PopActiveSnapshot(); and at this point surely it is not plancache's fault if there is any remaining refcount for the snapshot. There is, though, because GetTransactionSnapshot saved a refcount in TopTransactionResourceOwner. I think it's snapmgr.c's responsibility to make sure that that's cleaned up, and it's not doing so. The place where that refcount normally gets dropped is AtEarlyCommit_Snapshot, but that isn't going to be called at all in aborted-transaction cleanup. Worse, if we just transposed it over to be called in a place in AbortTransaction comparable to where it's called during commit, that still wouldn't fix the problem, because when the ROLLBACK happens, we've already aborted the transaction. I think that AtEarlyCommit_Snapshot is misdesigned, and that far from being done "early" in commit/abort, it needs to be done "late", like somewhere not very long before the ResourceOwnerDelete(TopTransactionResourceOwner) calls. There is no very good reason to think that someone might not ask for a snapshot during commit processing. Alvaro, do you happen to remember why this got designed as an "early" transaction shutdown action, rather than delaying it as long as possible? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
On Mon, Sep 26, 2011 at 12:20 PM, Robert Haas wrote: > On Mon, Sep 26, 2011 at 12:17 PM, Merlin Moncure wrote: >> hm. any relation to YAMAMOTO Takashi's recent email, [BUGS] bug in >> plancache.c, which hasn't hit the archives yet? >> >>> "GetCachedPlan can pass the 'qlist' to the planner twice. >> if i understand the code correctly, it's unsafe because the planner is >> destructive wrt the input tree. for my application, it often causes >> a crash in executor." > > I was just wondering about that. It seems like it could very well be > the same issue, but I have not tested it yet. OK, I tested it. On my system, that patch appears to fix this problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
Robert Haas writes: >> I was just wondering about that. It seems like it could very well be >> the same issue, but I have not tested it yet. > OK, I tested it. On my system, that patch appears to fix this problem. Yeah, I was just going to suggest that that might be related, but I see you beat me to the deduction. Will commit it (with more than zero comments) in a moment. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bug in plancache.c
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: > GetCachedPlan can pass the 'qlist' to the planner twice. > if i understand the code correctly, it's unsafe because the planner is > destructive wrt the input tree. for my application, it often causes > a crash in executor. Good catch, thanks! (But a fix like this really requires a comment IMO.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] comment fixes
On Fri, Sep 23, 2011 at 11:36 PM, YAMAMOTO Takashi wrote: > see the following patch. > it seems some function names in the comment are out of sync with the reality. Thanks, fixed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] reporting weirdness in configure output
I was building postgresql via Macports (with the debug flag on) and I saw this output -- including a notice to report this to pgsql-bugs@postgresql.org. So I'm doing so! ---> Configuring postgresql91 DEBUG: Using compiler 'Mac OS X llvm-gcc 4.2' DEBUG: Executing org.macports.configure (postgresql91) DEBUG: Environment: CPATH='/opt/local/include' CFLAGS='-pipe -O2 -arch x86_64' CPPFLAGS='-I/opt/local/include -I/opt/local/include/ossp' CXXFLAGS='-pipe -O2 -arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.7' CXX='/Developer/usr/bin/llvm-g++-4.2' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_singingwolfboy_Dropbox_ports_databases_postgresql91/postgresql91/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -O2 -m64' LDFLAGS='-L/opt/local/lib -arch x86_64' FCFLAGS='-pipe -O2 -m64' OBJC='/Developer/usr/bin/llvm-gcc-4.2' INSTALL='/usr/bin/install -c' PYTHON='/opt/local/bin/python2.7' OBJCFLAGS='-pipe -O2 -arch x86_64' FFLAGS='-pipe -O2 -m64' CC_PRINT_OPTIONS='YES' CC='/Developer/usr/bin/llvm-gcc-4.2' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_singingwolfboy_Dropbox_ports_databases_postgresql91/postgresql91/work/postgresql-9.1.1" && ./configure --prefix=/opt/local --sysconfdir=/opt/local/etc/postgresql91 --bindir=/opt/local/lib/postgresql91/bin --libdir=/opt/local/lib/postgresql91 --includedir=/opt/local/include/postgresql91 --datadir=/opt/local/share/postgresql91 --mandir=/opt/local/share/man --with-includes=/opt/local/include --with-libraries=/opt/local/lib --with-openssl --with-bonjour --with-readline --with-zlib --with-libxml --with-libxslt --enable-thread-safety --enable-integer-datetimes --with-ossp-uuid --with-python' DEBUG: Executing command line: cd "/opt/local/var/macports/build/_Users_singingwolfboy_Dropbox_ports_databases_postgresql91/postgresql91/work/postgresql-9.1.1" && ./configure --prefix=/opt/local --sysconfdir=/opt/local/etc/postgresql91 --bindir=/opt/local/lib/postgresql91/bin --libdir=/opt/local/lib/postgresql91 --includedir=/opt/local/include/postgresql91 --datadir=/opt/local/share/postgresql91 --mandir=/opt/local/share/man --with-includes=/opt/local/include --with-libraries=/opt/local/lib --with-openssl --with-bonjour --with-readline --with-zlib --with-libxml --with-libxslt --enable-thread-safety --enable-integer-datetimes --with-ossp-uuid --with-python checking build system type... x86_64-apple-darwin11.1.0 checking host system type... x86_64-apple-darwin11.1.0 checking which template to use... darwin checking whether to build with 64-bit integer date/time support... yes checking whether NLS is wanted... no checking for default port number... 5432 checking for block size... 8kB checking for segment size... 1GB checking for WAL block size... 8kB checking for WAL segment size... 16MB checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /Developer/usr/bin/llvm-gcc-4.2 accepts -g... yes checking for /Developer/usr/bin/llvm-gcc-4.2 option to accept ISO C89... none needed checking whether /Developer/usr/bin/llvm-gcc-4.2 supports -Wdeclaration-after-statement... yes checking whether /Developer/usr/bin/llvm-gcc-4.2 supports -Wendif-labels... yes checking whether /Developer/usr/bin/llvm-gcc-4.2 supports -Wformat-security... yes checking whether /Developer/usr/bin/llvm-gcc-4.2 supports -fno-strict-aliasing... yes checking whether /Developer/usr/bin/llvm-gcc-4.2 supports -fwrapv... yes checking whether the C compiler still works... yes checking how to run the C preprocessor... /Developer/usr/bin/llvm-gcc-4.2 -E checking allow thread-safe client libraries... yes checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... yes checking whether to build with GSSAPI support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with LDAP support... no checking whether to build with Bonjour support... yes checking whether to build with OpenSSL support... yes checking whether to build with SELinux support... no checking for xml2-config... xml2-config checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by GCC... /Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for ranlib... ranlib checking for strip... strip checking whether it is possible to strip libraries... no checking for ar... ar checking for tar... /usr/bin/tar checking whether ln -s works... yes checking for gawk... no checking for mawk... no checking for nawk.
[BUGS] BUG #6226: Broken foreign key stored on database (parent deleted with children still readable, BUG#6225 Update)
The following bug has been logged online:
Bug reference: 6226
Logged by: Daniel Cristian Cruz
Email address: danielcrist...@gmail.com
PostgreSQL version: 9.1.1
Operating system: "PostgreSQL 9.1.0 on x86_64-unknown-linux-gnu, compiled
by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit"
Description:Broken foreign key stored on database (parent deleted
with children still readable, BUG#6225 Update)
Details:
Hello,
Maybe my last message was very hard to read, English is not my natural
language and I'm with a strong headache (a real one, not about this
problem).
I've tested BUG #6225 in 9.1.1, and the problem persists. After deleting the
parent record, children record stills readable with a key that points to the
deleted record.
Script that shows the problem:
CREATE TABLE event (
id_event serial primary key
);
CREATE TABLE repetition_conf (
id_repetition_conf serial primary key,
id_event integer,
CONSTRAINT event_fk FOREIGN KEY (id_event) REFERENCES event (id_event)
ON UPDATE NO ACTION ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED
-- IF MAIN EVENT IS DELETED, REPETITION CONFIG IS DELETED TOO
);
CREATE TABLE repetition (
id_repetition serial primary key,
id_repetition_conf integer,
id_event integer,
CONSTRAINT repetition_conf_fk FOREIGN KEY (id_repetition_conf) REFERENCES
repetition_conf (id_repetition_conf)
ON UPDATE NO ACTION ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
-- IF REPETITION CONFIG IS DELETED, REPETITION IS DELETED TOO
CONSTRAINT event_fk FOREIGN KEY (id_event) REFERENCES event (id_event)
ON UPDATE NO ACTION ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED
-- IF EVENT IS DELETED, SET NULL TO REFERENCE (BUSINESS LOGIC)
);
CREATE OR REPLACE FUNCTION remove_event()
RETURNS trigger AS
$BODY$
BEGIN
DELETE FROM event
WHERE id_event = OLD.id_event;
RETURN OLD;
END
$BODY$
LANGUAGE plpgsql VOLATILE;
CREATE TRIGGER remove_repetition_event
BEFORE DELETE
ON repetition
FOR EACH ROW
WHEN ((OLD.id_event IS NOT NULL))
EXECUTE PROCEDURE remove_event();
-- IF REPETITION IS DELETED, EVENT IS DELETED TOO
-- ACTUAL INSERT STEPS
BEGIN;
INSERT INTO event (id_event) VALUES (DEFAULT); -- CREATE MAIN EVENT
INSERT INTO repetition_conf (id_event) VALUES
(CURRVAL('event_id_event_seq')); -- CREATE REPETITION CONFIG
-- THESE TWO NEXT STEPS ARE A LOOP IN A TRIGGER ON repetition_conf
INSERT INTO event (id_event) VALUES (DEFAULT);
INSERT INTO repetition (id_repetition, id_repetition_conf, id_event)
VALUES (DEFAULT, CURRVAL('repetition_conf_id_repetition_conf_seq'),
CURRVAL('event_id_event_seq'));
COMMIT;
-- IN ANOTHER SESSION, DELETE THE MAIN EVENT, WHICH WILL DELETE CONFIG AND
REPETITIONS
BEGIN;
DELETE FROM event WHERE id_event = 1;
COMMIT;
-- NOW I HAD A FOREIGN KEY WITH NO PARENT...
SELECT *
FROM repetition
LEFT JOIN repetition_conf
ON repetition.id_repetition_conf = repetition_conf.id_repetition_conf
WHERE repetition_conf.id_repetition_conf IS NULL;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6226: Broken foreign key stored on database (parent deleted with children still readable, BUG#6225 Update)
Excerpts from Daniel Cristian Cruz's message of lun sep 26 15:29:33 -0300 2011: > > The following bug has been logged online: > > Bug reference: 6226 > Logged by: Daniel Cristian Cruz > Email address: danielcrist...@gmail.com > PostgreSQL version: 9.1.1 > Operating system: "PostgreSQL 9.1.0 on x86_64-unknown-linux-gnu, compiled > by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit" > Description:Broken foreign key stored on database (parent deleted > with children still readable, BUG#6225 Update) > Details: > > Hello, > > Maybe my last message was very hard to read, English is not my natural > language and I'm with a strong headache (a real one, not about this > problem). Please see if bug #6123 applies to this case. http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg181541.html -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( "!(owner->nsnapshots == 0)", File: "resowner.c", Line: 365)
Excerpts from Tom Lane's message of lun sep 26 13:26:37 -0300 2011: > > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: > >> Maybe, but I'd still like to see a test case, because I can't reproduce > >> any such problem by preparing ROLLBACK in an aborted transaction. > > > reading GetTransactionSnapshot, it seems that the problem happens > > only with IsolationUsesXactSnapshot() true. > > Hmm. I'm inclined to think that this demonstrates a bug in snapshot > management, not so much in plancache. We have plancache doing > > PushActiveSnapshot(GetTransactionSnapshot()); > > and then later > > PopActiveSnapshot(); > > and at this point surely it is not plancache's fault if there is any > remaining refcount for the snapshot. There is, though, because > GetTransactionSnapshot saved a refcount in TopTransactionResourceOwner. > I think it's snapmgr.c's responsibility to make sure that that's cleaned > up, and it's not doing so. Agreed. > The place where that refcount normally gets dropped is > AtEarlyCommit_Snapshot, but that isn't going to be called at all in > aborted-transaction cleanup. Worse, if we just transposed it over to be > called in a place in AbortTransaction comparable to where it's called > during commit, that still wouldn't fix the problem, because when the > ROLLBACK happens, we've already aborted the transaction. ... ouch. > I think that AtEarlyCommit_Snapshot is misdesigned, and that far from > being done "early" in commit/abort, it needs to be done "late", like > somewhere not very long before the > ResourceOwnerDelete(TopTransactionResourceOwner) calls. There is no > very good reason to think that someone might not ask for a snapshot > during commit processing. > > Alvaro, do you happen to remember why this got designed as an "early" > transaction shutdown action, rather than delaying it as long as > possible? As far as I remember, the only principle was that it had to run before ResourceOwner cleanup. Commit 7b640b0345dc4fbd39ff568700985b432f6afa07 introduces that "early" call; ResOwner support had been introduced 10 days before in 6bbef4e5383c99d93aa974e2c79d328cfbd1c4a9. I probably just tried it out and noticed that resowner.c complained if I didn't drop the refcount prior to its own cleanup. I don't think I ever considered the scenario of calls in aborted transactions. Shall I work on a fix? I expect you are plenty busy with commitfest stuff, but please let me know otherwise. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( "!(owner->nsnapshots == 0)", File: "resowner.c", Line: 365)
Alvaro Herrera writes: > Excerpts from Tom Lane's message of lun sep 26 13:26:37 -0300 2011: >> The place where that refcount normally gets dropped is >> AtEarlyCommit_Snapshot, but that isn't going to be called at all in >> aborted-transaction cleanup. Worse, if we just transposed it over to be >> called in a place in AbortTransaction comparable to where it's called >> during commit, that still wouldn't fix the problem, because when the >> ROLLBACK happens, we've already aborted the transaction. > ... ouch. > Shall I work on a fix? I expect you are plenty busy with commitfest > stuff, but please let me know otherwise. I have what-I-think-is-the-fix pretty clear in my own mind, so let me give it a try. If it doesn't work I'll bounce it back to you. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pg 9.1.1 - ERROR: could not find pathkey item to sort
Is this a bug, or due to the way I am using the RANK() function in the following query? The error is triggered when I use (sum(y) / sum(x)) in the ORDER BY of the RANK() function. Simple test case: create table t (a int, b int, x numeric, y integer ); insert into t select g,round(mod(g,4)), round((random()*1000)::NUMERIC,2),round((random()*1000)::NUMERIC) from generate_series(1, 100) as g; select a, b, (sum(y) / sum(x)) as res, rank() over (partition by a,b order by (sum(y) / sum(x)) desc) as rank --rank() over (partition by a,b order by sum(y) desc) as rank -- no error from t group by a,b; select version(); version -- PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6), 64-bit Any other details needed? Cheers, Bricklen -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg 9.1.1 - ERROR: could not find pathkey item to sort
bricklen writes: > Is this a bug, Yes. Thanks for the test case, will look. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg 9.1.1 - ERROR: could not find pathkey item to sort
I wrote: > bricklen writes: >> Is this a bug, > Yes. Thanks for the test case, will look. Fixed, patch is at http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177 regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6227: No arguments for COPY OIDS and HEADER
The following bug has been logged online: Bug reference: 6227 Logged by: Itagaki Takahiro Email address: itagaki.takah...@gmail.com PostgreSQL version: 9.1 and all Operating system: N/A Description:No arguments for COPY OIDS and HEADER Details: Our documentation says OIDS and HEADER options in COPY command take [ boolean ] arguments, but actually they don't accept any arguments. We can only set them to TRUE by specifying their names. http://www.postgresql.org/docs/9.1/static/sql-copy.html - OIDS [ boolean ] - HEADER [ boolean ] [ boolean ] in copy.sgml seems a junk. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
