Re: a SELECT FOR UPDATE question
| От | Tom Lane |
|---|---|
| Тема | Re: a SELECT FOR UPDATE question |
| Дата | |
| Msg-id | 26510.1108047229@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: a SELECT FOR UPDATE question (Michael Fuhr <mike@fuhr.org>) |
| Ответы |
Re: a SELECT FOR UPDATE question
|
| Список | pgsql-general |
Michael Fuhr <mike@fuhr.org> writes:
> xactA: updates row
> xactB: attempts to update same row, blocks until xactA completes
> xactC: query finds xactA in row's xmax
> xactA: commits
> xactB: unblocks and acquires a lock on the row
> xactC: query to pg_locks doesn't find xactA, so assumes row not locked
> Does that sound like what you're talking about?
Right. Furthermore, xactC's query result could have been stale when it
was obtained, nevermind the separate query to pg_locks:
xactA: updates row
xactC: starts, sets snapshot
xactB: attempts to update same row, blocks until xactA completes
xactA: commits
xactB: unblocks and acquires a lock on the row
xactC: query finds xactA in row's xmax because of MVCC rules
regards, tom lane
В списке pgsql-general по дате отправления: