Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
От
Tom Lane
Тема
Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Дата
Msg-id
24715.949547413@sss.pgh.pa.us
Ответ на
RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts (Hiroshi Inoue)
Список
Дерево обсуждения
SELECT FOR UPDATE leaks relation refcounts Tom Lane <tgl@sss.pgh.pa.us>
RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts Tom Lane <tgl@sss.pgh.pa.us>
RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts wieck@debis.com (Jan Wieck)
Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts Bruce Momjian <pgman@candle.pha.pa.us>
"Hiroshi Inoue" writes: > I couldn't judge whether the following current behavior has some meaning > or not. > Let v be a view; > lock table v in exclusive mode; (I don't know what this means) Good question ... but it seems to me that it has to mean grabbing exclusive lock on the table(s) referred to by v. Otherwise, if client A locks the view and client B locks the underlying table directly, they'll both pass the lock and be able to access/modify the underlying table at the same time. That can't be right. The rewriter correctly passes SELECT FOR UPDATE locking from the view to the referenced tables, but I'm not sure whether it is bright enough to do the same for LOCK statements. (Jan?) regards, tom lane
В списке pgsql-hackers по дате отправления