Re: Revisited: Transactions, insert unique.

From: rmcm(at)compsoft(dot)com(dot)au
To: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
Cc: Joachim Achtzehnter <joachim(at)kraut(dot)bc(dot)ca>, pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Revisited: Transactions, insert unique.
Date: 2000-04-26 22:41:55
Message-ID: 14599.28852.8459.371311@fellini.mcmaster.wattle.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Doesn't

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

have to come within transaction - ie

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

In this order your test seems to behave correctly - only 1 row inserted.
--
Rex McMaster rex(at)mcmaster(dot)wattle(dot)id(dot)au
http://www.compsoft.com.au/~rmcm/pgp-pk

Ed Loehr writes:
>
> But the following sequence seems to contradict this:
>
> -- Transaction A
> DROP TABLE foo;
> CREATE TABLE foo (id INTEGER);
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> BEGIN;
> -- Transaction B
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> BEGIN;
> INSERT INTO foo (id) SELECT 1 WHERE NOT EXISTS (SELECT * FROM foo WHERE id
> = 1);
> COMMIT;
> SELECT * FROM foo;
> -- Transaction A
> SELECT * FROM foo;
> INSERT INTO foo (id) SELECT 1 WHERE NOT EXISTS (SELECT * FROM foo WHERE id
> = 1);
> SELECT * FROM foo;
> COMMIT;
>
> This sequence allows B's inserts, AFTER A began, to be seen by A (at least,
> in pgsql 7.0beta3).
>
> Anyone understand what's going on here? Bug?
>
> Regards,
> Ed Loehr

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ed Loehr 2000-04-26 22:52:44 Re: Revisited: Transactions, insert unique.
Previous Message Michael S. Kelly 2000-04-26 22:21:33 I'm just doin' the 7.0 RC1 install and have some input on the documentation.