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.

> 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
> 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
> info at the moment.  (You can see xmax at the user level, but you
> easily tell if xmax is trying to delete the row or just lock it,
> you don't have access to the infomask bit that would tell you.)
>                       regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to