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