Thread: Re: BUG #1266: Improper unique constraint / MVCCactivitieswithin

Re: BUG #1266: Improper unique constraint / MVCCactivitieswithin

From
Stephan Szabo
Date:
On Sun, 26 Sep 2004, Aleksey Fedorchenko wrote:

> As i told, under pgAdmin's console and PHP it fails anyway but psql
> falls only with function invocation.

Hmm, for PHP was it sent as one big string with all the statements or a
separate statements?  There's a side issue that I believe you can send
multiple statements in one query string, but they're treated specially if
you do so.

> > In the former case there's a reading of spec
> > question for the timing of the actions (are they on the statement or at
> > check time -- we've done the latter although a rereading implies that we
> > may have previously read it wrong) and the latter, up until Tom's very
> > recent patch, any AFTER triggers (or foreign keys) waited until the end of
> > the original statement from the user to run.
>
> I misunderstood this sentence... Do you wanna told me that within single
> statements batch there could be non-serializable execution? If true then
> it seems to be a architectual issue (i could expect parallel execution
> within single sql statement but all constraints have to be checked right
> after it finished - not before and not after, just at a statement
> execution finish moment). Otherwise it is a bug anyway, imho.

What I'm saying is that, constraints are checked at end of statement.  In
current releases (8.0b2 included I believe but not 8.0b3) functions are
considered part of the statement that called them, so the constraints are
check at the end of the full outer statement that called the function.
8.0b3 should change this so that the inner statements are considered
separately. In addition, referential actions are currently (but may not be
in 8.0 final) considered to occur at constraint check time, which means
for a deferred constraint, at end of transaction or when set constraints
is used to make the constraint immediate.  The reason the latter may
change is that with rereading the spec we are not sure if that is actually
what the spec intends and are still investigating that.

Re: BUG #1266: Improper unique constraint / MVCCactivitieswithin

From
Stephan Szabo
Date:
On Sun, 26 Sep 2004, Stephan Szabo wrote:

> What I'm saying is that, constraints are checked at end of statement.  In
> current releases (8.0b2 included I believe but not 8.0b3) functions are
> considered part of the statement that called them, so the constraints are
> check at the end of the full outer statement that called the function.
> 8.0b3 should change this so that the inner statements are considered
> separately. In addition, referential actions are currently (but may not be

And in current sources, functions 2 and 3 error with foreign key
violations rather than unique constraint violations.  If the constraint
was deferred you'd still get the unique violations, but we're still
looking to see which error is correct in that case.

Re: BUG #1266: Improper unique constraint / MVCCactivitieswithin

From
"Aleksey Fedorchenko"
Date:
> And in current sources, functions 2 and 3 error with foreign key
> violations rather than unique constraint violations.  If the constraint
> was deferred you'd still get the unique violations, but we're still
> looking to see which error is correct in that case.

Does it mean that scripts that i sent you yesterday works fine and their results are proper (in mean of proper reaction
onimproper user activities) and different from described by me in first letter? 

Its strange because i tuned SET CONSTRAINTS in different modes but it didn't take any effect - i still have same
results!

Did you apply any patches on your pgsql instance? Because i have 3 distribs (7.4.2/8.0.0b1/8.0.0b2) and all fails the
sameway.