Обсуждение: pl/pgsql and Transaction Isolation

Поиск
Список
Период
Сортировка

pl/pgsql and Transaction Isolation

От
Marcus Whitney
Дата:
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

Re: pl/pgsql and Transaction Isolation

От
Tom Lane
Дата:
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

Re: pl/pgsql and Transaction Isolation

От
Marcus Whitney
Дата:
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