From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-08 06:25:52 |
Message-ID: | 20050208062552.GA98003@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Feb 08, 2005 at 12:58:34AM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> >
> > I think you can infer that a process is working with a row in some
> > manner (UPDATE, SELECT FOR UPDATE) by looking at the row's xmax
> > column and checking pg_locks to see if any process is holding a
> > lock on the indicated transaction ID.
>
> I'm too tired to work out an example, but I think this probably doesn't
> work in general: the xmax on the version of the row you can see might
> not correspond to a live transaction, but that doesn't mean someone
> else doesn't hold a lock on the latest committed version of the row.
Okay...I had done some tests with UPDATE and SELECT FOR UPDATE and
observed what I wrote, but admittedly that covers only a few cases.
If you could point me in the right direction I'll try to work out
an example where my suggestion fails.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Clements | 2005-02-08 06:27:55 | Re: Problem performing a restore of a data schema in Wi |
Previous Message | Tom Lane | 2005-02-08 05:58:34 | Re: a SELECT FOR UPDATE question |