moving to -hackers since the patch is already in...

On Wednesday 05 September 2007 18:12, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Florian G. Pflug wrote:
> >> So, in essence, you get the old pg_locks format back by doing
> >> select l1.*, l2.transactionid as "transaction" from pg_locks l1,
> >> pg_locks l2
> >> where l1.vxid = l2.vxid and l2.locktype = 'transaction'
> >> and l2.mode='exclusive' and l2.granted=true.
> You'd want some sort of left join, no doubt, else you're not going to
> see transactions that have not got an XID.
> > or make it a system view?
> That would be a bit silly.  If there's actually still a use-case for the
> XID column then we should just put it back. 

I agree, adding a system view to make up for removing a column seems like the 
wrong solution to me. 

> I don't actually see a 
> reasonable use-case for it though.  As Florian points out, you can get
> it if you really need it --- but that view is already annoyingly wide,
> and I'm not eager to burden it with columns that are usually useless.

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.  

> 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. I would agree that the 
behavior of the column has changed, so it might cause some odd behvaior in 
apps that rely on it.  

Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to