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

Thu, 27 Feb 2003 17:14:44 -0500
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: Can pessimistic locking be emulated? 