Michael Fuhr <[EMAIL PROTECTED]> 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 tr
On Thu, Feb 10, 2005 at 10:40:44AM -0500, Tom Lane wrote:
>
> Remember RC mode takes a new snapshot for each query. You'd need to
> use serializable mode --- and do something to actually freeze the
> transaction snapshot, which BEGIN does not --- to see the issue in a
> manual test.
It sounds li
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Feb 10, 2005 at 09:53:49AM -0500, Tom Lane wrote:
>> xactC: starts, sets snapshot
> Hmmm...that's not what I'm seeing in 8.0.1, at least not when
> xactC is READ COMMITTED:
Remember RC mode takes a new snapshot for each query. You'd need to
use
On Thu, Feb 10, 2005 at 09:53:49AM -0500, Tom Lane wrote:
>
> 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
Michael Fuhr <[EMAIL PROTECTED]> 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 n
On Tue, Feb 08, 2005 at 01:45:44AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> 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 yo
Michael Fuhr <[EMAIL PROTECTED]> 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
On Tue, Feb 08, 2005 at 12:58:34AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> 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
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Feb 07, 2005 at 03:08:12PM -0800, Tim Vadnais wrote:
>> If I select a row for update, is there anyway that someone can query to see
>> if that row has been 'selected for update' and by whom?
> I think you can infer that a process is working with
On Mon, Feb 07, 2005 at 03:08:12PM -0800, Tim Vadnais wrote:
>
> If I select a row for update, is there anyway that someone can query to see
> if that row has been 'selected for update' and by whom?
I think you can infer that a process is working with a row in some
manner (UPDATE, SELECT FOR UPD
Title: a SELECT FOR UPDATE question
Hi,
If I select a row for update, is there anyway that someone can query to see if that row has been 'selected for update' and by whom?
Then I'd like to know if the session that 'SELECT(ed) FOR UPDATE' dies, will the server release the locked row?
Than
11 matches
Mail list logo
