Re: determine snapshot after obtaining locks for first statement

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: determine snapshot after obtaining locks for first statement
Дата
Msg-id 4B2A2139020000250002D719@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: determine snapshot after obtaining locks for first statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: determine snapshot after obtaining locks for first statement
Re: determine snapshot after obtaining locks for firststatement
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After thinking a bit, I'd be inclined to add a new paragraph.
> In particular, now that FOR UPDATE actually works in subqueries,
> it'd be worth pointing out that you can add that to guard against
> this type of issue.  Perhaps, after the "DELETE FROM website"
> example, we could add something like
> 
> UPDATEs and DELETEs involving joins or subqueries are particularly
> at risk, since they may perform an update based on a combination
> of old rows from other tables with an up-to-date target row.  This
> risk can be mitigated by adding FOR UPDATE or FOR SHARE to
> subqueries, so that all rows directly involved in an update are
> guaranteed current.  However that will also increase the risk of
> deadlock failures.
Much better than my suggestion.  Including both the problem
conditions and the solution is ideal.
I'd missed that we now allow FOR UPDATE and FOR SHARE on subqueries.
Nice enhancement.
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: determine snapshot after obtaining locks for first statement
Следующее
От: Tom Lane
Дата:
Сообщение: Re: determine snapshot after obtaining locks for first statement