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
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 |
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 |