Thread: pl/pgsql and Transaction Isolation
Hello, I have an instance where I have a series of pl/pgsql calls, that report stat results to a common table. When other queries try to hit the stat table (with DML commands; SELECT, INSERT, UPDATE, DELETE etc.) they are forced to wait in a queue until the pl/pgsql has finished executing. will: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; before these DML queries eliminate the locking? -- marcus whitney chief architect : cold feet creative www.coldfeetcreative.com 800.595.4401 cold feet presents emma email marketing for discriminating organizations everywhere visit www.myemma.com
Marcus Whitney <marcus@coldfeetcreative.com> writes: > I have an instance where I have a series of pl/pgsql calls, that report stat > results to a common table. When other queries try to hit the stat table > (with DML commands; SELECT, INSERT, UPDATE, DELETE etc.) they are forced to > wait in a queue until the pl/pgsql has finished executing. This is quite hard to believe, unless your pl/pgsql is doing something as unfriendly as LOCKing the table. Do you want to post a more complete description of your problem? regards, tom lane
You were right not to believe it. I had an update on a whole table that I hadn't noticed. Thanks for debunking. On Monday 07 June 2004 23:29, you wrote: > Marcus Whitney <marcus@coldfeetcreative.com> writes: > > I have an instance where I have a series of pl/pgsql calls, that report > > stat results to a common table. When other queries try to hit the stat > > table (with DML commands; SELECT, INSERT, UPDATE, DELETE etc.) they are > > forced to wait in a queue until the pl/pgsql has finished executing. > > This is quite hard to believe, unless your pl/pgsql is doing something > as unfriendly as LOCKing the table. > > Do you want to post a more complete description of your problem? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- marcus whitney