| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | Mauri Sahlberg <Mauri(dot)Sahlberg(at)pretax(dot)net> |
| Cc: | <pgsql-admin(at)postgresql(dot)org>, <petri(dot)hilska(at)pretax(dot)net> |
| Subject: | Re: Parallel transactions failing oddly |
| Date: | 2003-08-01 05:51:40 |
| Message-ID: | 20030731224348.M37793-100000@megazone.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 1 Aug 2003, Mauri Sahlberg wrote:
> On pe, 2003-08-01 at 03:12, Stephan Szabo wrote:
> > > interface. If we run them one by one everything goes fine. But if I
> > > run them in parallel - in separate processes - all but the first one
> > > claiming the lock for "ryhmalaiset"-table will fail. And they will
> > > fail as soon as the first one is finished by trying to insert
> > > duplicate row in the shared table. Incidentally this row would also be
> > > the very first row they are trying to insert. They all run the same code
> > > but with different data.
> > >
> > The second transaction won't see the row inserted by the first transaction
> > until it commits (at best). Both transactions can think there are no
> > matching rows.
>
> Umh, but as the "ryhmalaiset" table is locked until the transaction is
> commited? And what do you mean with "at best"? Is there any way ensuring
> that the other transactions won't access the table until the first one
> has finished updating it if the lock is not enough?
I said at best because I dont think serializable mode transactions won't
see the row even after commit as long as its snapshot's been taken
already. You are locking the table in access exclusive mode right?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2003-08-01 05:53:52 | Re: fyi |
| Previous Message | Mauri Sahlberg | 2003-08-01 05:26:26 | Re: Parallel transactions failing oddly |