Re: table locking

Поиск
Список
Период
Сортировка
Искать
От
Bruce Momjian
Тема
Re: table locking
Дата
Msg-id
200202181534.g1IFYDP19471@candle.pha.pa.us
Ответ на
Re: table locking (Shane Wright)
Список
Дерево обсуждения
table locking Shane Wright <me@shanewright.co.uk>
Re: table locking Bruce Momjian <pgman@candle.pha.pa.us>
Re: table locking Shane Wright <me@shanewright.co.uk>
Re: table locking Tom Lane <tgl@sss.pgh.pa.us>
Re: table locking Shane Wright <me@shanewright.co.uk>
Re: table locking Shane Wright <me@shanewright.co.uk>
Re: table locking Bruce Momjian <pgman@candle.pha.pa.us>
Re: table locking Shane Wright <me@shanewright.co.uk>
Shane Wright wrote:
> Hi Bruce
> 
> Thanks for the information (and the book link, straight in the bookmarks and 
> remembered for an Amazon search...)
> 
> Anyway, the chapter was helpful, but I'm still stuck.  SERIALIZABLE looks 
> like it would do the job, but I don't want any queries to fail/rollback - I'd 
> rather they stalled on SET TRANSACTION or LOCK TABLE until the first was 
> complete.
> 
> Is this possible?
> 
> I am also assuming that even with SERIALIZABLE, concurrent SELECTs can 
> proceed unhindered?

Actually, I think the default READ COMMITTED will work fine for you. 
Backends will block waiting for your write, then continue when you
commit, and reads will not be affected.  I am not totally sure what you
are testing, so I suggest starting two psql sessions and trying it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610) 853-3000 +  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

В списке pgsql-sql по дате отправления
От: Tom Lane
Дата:
Сообщение: Re: Sequence in the rules
От: Tom Lane
Дата:
Сообщение: Re: table locking
FAQ