Re: I'm puzzled by a foreign key constraint problem - Mailing list pgsql-general

From Jonathan Guthrie
Subject Re: I'm puzzled by a foreign key constraint problem
Date
Msg-id 1225830872.3821.152.camel@localhost.localdomain
Whole thread Raw
In response to Re: I'm puzzled by a foreign key constraint problem  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: I'm puzzled by a foreign key constraint problem
Re: I'm puzzled by a foreign key constraint problem
List pgsql-general
On Wed, 2008-11-05 at 04:40 +0900, Craig Ringer wrote:
> The point is that if your initial create and the setting of the initial
> permissions must succeed or fail together, they MUST be done within a
> single transaction. That is, in fact, the fundamental point of database
> transactions.

I understand that.  Honestly, I do.  If I hadn't ever said that odd
things happen when the permissions aren't set, then maybe I could find
out what I'm doing wrong.

> What you should avoid doing is:
>
> TRANSACTION 1                 TRANSACTION 2
>
> BEGIN;
>                               BEGIN;
> SELECT create_it(blah);
>                               SELECT set_permissions(blah, perms);
> COMMIT;
>                               COMMIT;
>
> ... because that just won't work. It sounds like you've got that right,
> but you might be doing this:

> TRANSACTION 1                 TRANSACTION 2
>
> BEGIN;
>                               BEGIN;
>                               SET transaction_isolation = SERIALIZABLE;
>                               -- do something else that triggers
>                               -- freezing of the transaction's snapshot,
>                               -- even something like:
>                               SELECT 1;
> SELECT create_it(blah);
> COMMIT;
>                               SELECT set_permissions(blah, perms);
>                               COMMIT;
>
> ... which will also fail.

The thing is, the C++ code does this

BEGIN transaction 1
INSERT project
COMMIT

BEGIN transaction 2
SET permissions
COMMIT

or, at least, it's supposed to.  Those two operations are not supposed
to overlap at all even if they're on two different connections.  I
thought I had verified this by looking at the log file.  I mean, I can
look at the log file and see things like

2008-11-03 16:29:22 CST DEBUG:  00000: StartTransactionCommand
and
2008-11-03 16:29:22 CST DEBUG:  00000: CommitTransactionCommand

where I would expect them to if what I'm expecting is going on, but the
log file doesn't appear to have enough information to see a transaction
created, proceed, and then end.  That is, how do I know which
transaction was started and which one was committed?

I'm kind of confused by lines like this:

2008-11-03 16:29:22 CST DEBUG:  00000: name: unnamed; blockState:    INPROGRESS; state: INPROGR, xid/subid/cid:
678145/1/4,nestlvl: 1, children: 678146 678147 

Is there an easy explanation somewhere?



pgsql-general by date:

Previous
From: Steve Atkins
Date:
Subject: Re: Semi-customized queries? Subset of SQL? Accessing the parser? Injection?
Next
From: Tom Allison
Date:
Subject: Re: postgresql and Mac OS X