Re: [PATCHES] Lazy xid assignment V4 - Mailing list pgsql-hackers

From Robert Treat
Subject Re: [PATCHES] Lazy xid assignment V4
Date
Msg-id 200709051835.32454.xzilla@users.sourceforge.net
Whole thread Raw
Responses Re: [PATCHES] Lazy xid assignment V4
List pgsql-hackers
moving to -hackers since the patch is already in...

On Wednesday 05 September 2007 18:12, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Final background writer cleanup for 8.3
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Lazy xid assignment V4