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

Reply via email to