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-08 06:45:44 |
Message-ID: | 3220.1107845144@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:
> On Tue, Feb 08, 2005 at 12:58:34AM -0500, Tom Lane wrote:
>> 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.
> If you could point me in the right direction I'll try to work out
> an example where my suggestion fails.
I'm thinking about a multiple-update situation: your snapshot includes
row version A, which was superseded by version B, which was superseded
by version C. By the time you are looking, the transaction that
committed version B is gone so the xmax you see (B's xact) isn't locked
anymore. But the "frontmost" version of the row is still locked (by C
or some later heir) so if you tried to update you'd block.
Like I said, I'm pretty tired and I might be missing something...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Surabhi Ahuja | 2005-02-08 07:55:23 | |
Previous Message | Shaun Clements | 2005-02-08 06:27:55 | Re: Problem performing a restore of a data schema in Wi |