| 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-11 02:57:10 |
| Message-ID: | 5855.1108090630@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:
> It sounds like the best a check could do would be the amazingly
> astute "some transaction held a lock on this row at one time and
> may or may not still hold that lock, and even if it did when you
> checked it might have gone away by now and some other transaction
> that you don't know about might hold a lock."
> Does that about sum it up? ;-)
Yeah. Really, if you want to inspect the state of a lock,
the only meaningful operation is to try to acquire the lock.
It's reasonable to offer an "acquire only if immediately available"
operation --- but reporting on the instantaneous state seems
pretty useless by itself.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2005-02-11 03:03:21 | Re: Understanding EXPLAIN ANALYZE output |
| Previous Message | Alex Turner | 2005-02-11 02:56:00 | Python Driver |