| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> |
| Cc: | Tim Vadnais <tvadnais(at)bwks(dot)com>, "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: a SELECT FOR UPDATE question |
| Date: | 2005-02-10 14:53:49 |
| Message-ID: | 26510.1108047229@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ed L. | 2005-02-10 15:04:52 | Re: Understanding EXPLAIN ANALYZE output |
| Previous Message | Richard Plotkin | 2005-02-10 14:07:23 | How to fake an array of a user-defined type |