RE: transaction safety
От
fabrizio.ermini@sysdat.it
Тема
RE: transaction safety
Дата
Msg-id
3A8927D7.17555.CDA739@localhost
Ответ на
RE: transaction safety (Michael Ansley)
Список
Дерево обсуждения
RE: transaction safety Michael Ansley <Michael.Ansley@intec-telecom-systems.com>
RE: transaction safety fabrizio.ermini@sysdat.it
Re: transaction safety DaVinci <bombadil@wanadoo.es>
How to limit the size of pg_log ?? Jean-Arthur Silve <jeanarthur@eurovox.fr>
Re: transaction safety Tom Lane <tgl@sss.pgh.pa.us>
Re: transaction safety DaVinci <bombadil@wanadoo.es>
Re: transaction safety DaVinci <bombadil@wanadoo.es>
Re: transaction safety Jan Wieck <janwieck@Yahoo.com>
Re: transaction safety DaVinci <bombadil@wanadoo.es>
Re: transaction safety Jan Wieck <janwieck@Yahoo.com>
On 13 Feb 2001, at 10:58, Michael Ansley wrote: > OK, someone want to answer this? I have always been under the impression > that Postgres would not block under these circumstances, however, this is > clearly blocking, for no apparently good reason. > > I have just run a test on my own server, and this blocking does not happen. > Both sessions run independently until each has committed, then displaying > information from the other insert, but definitely not blocking. It works > exactly as I would have expected. > This thing has ignited my curiosity, too. I've tested it on a server and I've obtained your same results, no blocking, as should be. Don't understand why David experiences a lock. Maybe it has "SET TRANSACTION SERIALIZABLE" on? Could that be of some influence? Or maybe it's something that's in those "..." in his examples, but it seems strange. just my 0.02 Euro Ciao! /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Fabrizio Ermini Alternate E-mail: C.so Umberto, 7 faermini@tin.it loc. Meleto Valdarno Mail on GSM: (keep it short!) 52020 Cavriglia (AR) faermini@sms.tin.it
В списке pgsql-general по дате отправления