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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
