Robert Treat <[EMAIL PROTECTED]> writes: > I'm trying to decide how reasonable the use case is. We have transactions > that > run several hours long, often touching a number of tables, and I've used the > transaction to get a list of all of the relations a given transaction is > touching. This makes the above solution more annoying by far, but I don't do > it often, and I think I generally use the pid to get that information anyway; > if I used prepared transactions I'm sure I'd feel stronger about this.
I don't see why you wouldn't start using the VXID for this purpose? >> Also, I still agree with Florian's earlier argument that we should >> deliberately break any code that's depending on the transaction column. >> Any such code is unlikely to be prepared for the column containing nulls. > I don't buy this argument really only so far as the column can already be > null, so apps already need a way to deal with that. No, it was not possible for the XID column to be null before. Up to now, if you didn't have an XID you weren't holding a lock. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings