Обсуждение: Re: [PATCHES] Lazy xid assignment V4

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

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

On Wednesday 05 September 2007 18:40, Tom Lane wrote:
> 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?
>

I'm not sure either :-)  Though, it would be nice to have an easy way to see 
which transactions actually modified tables.  Again, I not sure the use case 
is reasonable, but it's there. If no one else feels strongly, let's document 
a query to mimic the old column and move on. 

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

Robert Treat <xzilla@users.sourceforge.net> writes:
> On Wednesday 05 September 2007 18:40, Tom Lane wrote:
>> I don't see why you wouldn't start using the VXID for this purpose?

> I'm not sure either :-)  Though, it would be nice to have an easy way to see 
> which transactions actually modified tables.

Moving the goal posts, aren't we?  It was not possible to find that out
at all from the pg_locks view before.  (Well, you could guess based on
the type of table locks held, but you were only guessing.)

As of CVS HEAD you *can* determine that from pg_locks, to high
probability anyway, by looking to see which VXIDs have transaction IDs
locked.
        regards, tom lane