Skip site navigation (1) Skip section navigation (2)

Re: Can pessimistic locking be emulated?

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Christoph Haller" <ch(at)rodos(dot)fzk(dot)de>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can pessimistic locking be emulated?
Date: 2003-02-27 16:43:09
Message-ID: 303E00EBDD07B943924382E153890E5434A91D@cuthbert.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I was referring to 10.3 in the administrator's guide, regarding the
pg_lock view.  According to the documentation, the view only contains
table level locks.  However, the view also contains an xid for
transactions.  The unclear part, at least to me, was what the role of
the xid was in the view and if it could be used to produce a list of
locked tuples somehow.  The xid is referred to as a 'lockable object'.
I wasn't sure of the xid's role in the mix.  I see now how it all works

In my case, being able to view outstanding row level locks would be
enormously useful.  I'm assuming this is not possible for structural or
performance reasons.  I'm aware of the possible nasty side affects of
repeated query calls to the lock manager.  I'm also aware what I'm
asking about may be folly or silly, my understanding of how mvcc and
transactions work together is not very refined.

A curious thought struck me: does the pg_lock view follow the mvcc
rules, i.e. if you query the pg_lock view inside a transaction, and an
external effect introduces new locks into the server are you able to see
those locks?

> > 1. Can you query if a tuple is locked by another transaction (the
> > documentation unclearly suggests this can't be done via the pg_lock
> > view) before executing select for update...?

> Where did you find this?

> Regards, Christoph


pgsql-hackers by date

Next:From: Robert TreatDate: 2003-02-27 17:04:07
Subject: Re: Free-space-map management thoughts
Previous:From: Ross J. ReedstromDate: 2003-02-27 16:31:01
Subject: Re: [HACKERS] Simplifying timezone support

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group