Re: Can pessimistic locking be emulated?

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can pessimistic locking be emulated?
Date: 2003-02-27 22:14:44
Message-ID: 303E00EBDD07B943924382E153890E5434A91E@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This directly answers my question (wasn't previously aware that xid
could be queried out in such a useful fashion). Not only does this
accomplish what I need, but now allows me to not use select ... for
update and stick with a transaction based locking mechanism. The 'Why'
isn't that interesting in my case: merely that the knowledge that the
record is involved in a transaction is enough.

I've felt for a while that the descriptions of transactions, mvcc, and
row level locking in the official docs could use a little bit better
treatment (selfishly motivated, I could never figure them completely
out!) but this is the wrong list for that :).

Many thanks to the hackers for helping me with my problem.
Merlin

>
> Actually, I don't think you need a dirty read at all. A locked row
> can't be deleted as well (because there's only one xmax slot), so if
you
> can see it (ie, you think its xmin is committed) then you can in
> principle find out whether it's locked or not. We just don't expose
the
> info at the moment. (You can see xmax at the user level, but you
can't
> easily tell if xmax is trying to delete the row or just lock it,
because
> you don't have access to the infomask bit that would tell you.)
>
> regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-27 22:21:15 Re: Free-space-map management thoughts
Previous Message Tom Lane 2003-02-27 22:10:25 Re: Free-space-map management thoughts