From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
Cc: | PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Lazy xid assignment V4 |
Date: | 2007-09-05 03:49:49 |
Message-ID: | 28579.1188964189@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> Here is an updated patch, following the discussion.
> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
I've been working through this, and found a couple items that seem like
judgment calls:
* Is there a good reason for formatting VXIDs as %d/%X rather than
%d/%u? There are no other columns in pg_locks that we use hex for,
so this seems a bit jarring.
* What is the rationale for keeping the transaction column in pg_locks?
The useful uniqueness/join column will be virtualtransaction. I don't
see a very strong backwards-compatibility argument for keeping it,
because any code that depends on it being there probably thinks it's a
unique key, which it cannot be anymore.
One could actually make an argument to rename the virtualtransaction
column as transaction. This will avoid breaking client code that thinks
that the transaction column is a unique key and isn't too wedded to the
assumption that the contents look like an integer. If it is so wedded,
it's most likely busted anyway by the possibility that the column is
null...
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2007-09-05 03:52:08 | HEAD build troubles, buildfarm misconfigurations |
Previous Message | John DeSoi | 2007-09-05 03:49:45 | Re: Has anyone tried out the PL/pgSQL debugger? |
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2007-09-05 09:49:30 | GSS warnings |
Previous Message | Gregory Stark | 2007-09-04 23:20:25 | Re: HOT documentation README |