Re: Parallel transactions failing oddly

From: Mauri Sahlberg <Mauri(dot)Sahlberg(at)claymountain(dot)com>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
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:56:10
Message-ID: 1059717370.6233.42.camel@taekwondo.intra.pretax.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On pe, 2003-08-01 at 08:51, Stephan Szabo wrote:
> 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?

Yes.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Stephan Szabo 2003-08-01 06:07:53 Re: Parallel transactions failing oddly
Previous Message Stephan Szabo 2003-08-01 05:53:52 Re: fyi