Re: Parallel transactions failing oddly
От
Mauri Sahlberg
Тема
Re: Parallel transactions failing oddly
Дата
Msg-id
1059715585.6233.22.camel@taekwondo.intra.pretax.net
Ответ на
Re: Parallel transactions failing oddly (Stephan Szabo)
Список
Дерево обсуждения
Parallel transactions failing oddly Mauri Sahlberg <Mauri.Sahlberg@pretax.net>
Re: Parallel transactions failing oddly Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Parallel transactions failing oddly Mauri Sahlberg <Mauri.Sahlberg@pretax.net>
Re: Parallel transactions failing oddly Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Parallel transactions failing oddly Mauri Sahlberg <Mauri.Sahlberg@claymountain.com>
Re: Parallel transactions failing oddly Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Parallel transactions failing oddly Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Parallel transactions failing oddly Mauri Sahlberg <Mauri.Sahlberg@claymountain.com>
Re: Parallel transactions failing oddly Mauri Sahlberg <Mauri.Sahlberg@claymountain.com>
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?
В списке pgsql-admin по дате отправления