Robert Treat <xzilla@users.sourceforge.net> 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
