From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nested xacts: looking for testers and review |
Date: | 2004-06-12 17:27:15 |
Message-ID: | 20040612102200.W90985@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 10 Jun 2004, Alvaro Herrera wrote:
> On Wed, Jun 09, 2004 at 11:32:08PM -0700, Stephan Szabo wrote:
>
> > > Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> > > at work, so I'm doing it during compilations and such.)
>
> [...]
>
> > Okay - I think I see what's going on here.
> >
> > It looks like deferredTriggerInvokeEvents is being run (immediate_only),
> > but since deferredTriggers->events_imm is NULL it's using
> > deferredTriggers->events as the start of the list to check, but this value
> > isn't getting reset in DeferredTriggerEndSubXact in the case that the
> > entire list was created in an aborted subtransaction.
>
> Ok, thanks for the test and diagnostics; patch attached. I'll see if I
> can find other situations like this.
As a question, what was the general assumption about what the following
should do (using a modification of the original test case)?
DROP TABLE foo CASCADE;
DROP TABLE bar CASCADE;
CREATE TABLE foo (A INT UNIQUE);
CREATE TABLE bar (A INT REFERENCES foo(A) DEFERRABLE);
DELETE FROM bar;
DELETE FROM foo;
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
INSERT INTO bar VALUES (1);
BEGIN;
INSERT INTO bar VALUES (3);
COMMIT;
BEGIN;
BEGIN;
INSERT INTO bar VALUES (4);
COMMIT;
INSERT INTO foo VALUES (3);
SET CONSTRAINTS ALL IMMEDIATE;
ROLLBACK;
-- move this set constraints down below
-- SET CONSTRAINTS ALL DEFERRED;
BEGIN;
INSERT INTO bar VALUES (5); --(1)
COMMIT;
SET CONSTRAINTS ALL DEFERRED;
BEGIN;
BEGIN;
INSERT INTO bar VALUES (6);
ROLLBACK;
COMMIT;
BEGIN;
INSERT INTO bar VALUES (7);
COMMIT;
BEGIN;
BEGIN;
INSERT INTO bar VALUES (9);
COMMIT;
COMMIT;
INSERT INTO foo VALUES(3);
INSERT INTO foo VALUES(5);
INSERT INTO foo VALUES(7);
INSERT INTO foo VALUES(9);
COMMIT;
Should the statement at (1) fail because the constraint is not immediately
satisfied, or should it pass because the set constraints all immediate was
part of a subtransaction that didn't commit?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-06-12 17:44:08 | Re: [COMMITTERS] pgsql-server: Clean up generation of default |
Previous Message | Tom Lane | 2004-06-12 16:58:21 | Re: Bug in RENAME TO? |