Re: Lazy xid assignment V4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Lazy xid assignment V4
Date: 2007-09-05 22:12:55
Message-ID: 26409.1189030375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)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 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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2007-09-05 22:35:31 Re: [PATCHES] Lazy xid assignment V4
Previous Message Florian G. Pflug 2007-09-05 22:07:53 Re: Lazy xid assignment V4

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-05 22:15:36 Re: HOT patch - version 15
Previous Message Florian G. Pflug 2007-09-05 22:07:53 Re: Lazy xid assignment V4