On Thu, Dec 19, 2013 at 9:22 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Jim Nasby escribió:
>> One thing users will lose in this patch is the ability to reliably see if a tuple is frozen via SQL. Today you can
dothat just by selecting xmin from the table.
>>
>> Obviously people don't generally need to do that... but it's one of those things that when you do need it it's
incrediblyhandy to have... would it be difficult to expose infomask(2) via SQL, the same way xmin et all are?
>
> It's already exposed via the pageinspect extension. It's doubtful that
> there are many valid cases where you need infomask but don't have access
> to that module.
>
> The real fix seems to ensure that the module is always available.
We could make the code that displays this column do GetXmin rather
than GetRawXmin, which would allow this question to be answered, but
lose the ability to find the original xmin once the tuple is frozen
and break precedent with the xmax and cmin/cmax fields, which return
the "raw" value from the tuple header. But I'm OK to go whichever
direction people prefer.
I think the root of the problem is that nobody's very eager to add
more hidden system catalog columns because each one bloats
pg_attribute significantly. Currently, we have xmin, xmax, cmin, and
cmax columns, and that's basically just a historical artifact at this
point. cmin and cmax always return the same value, and the value
returned may be neither a cmin nor a cmax but a combo CID. And if
you're looking for information that's only in the infomask, good luck.
Maybe what we should do is add a function something like
pg_tuple_header(tableoid, ctid) that returns a record, maybe something
like (rawxmin xid, rawxmax xid, rawcid cid, infomask int, infomask2
int, hoff int). Or perhaps some slightly more cooked version of that
information. And then delete the xmin, xmax, cmin, and cmax system
columns. That'd save significantly on pg_attribute entries while, at
the same time, actually providing more information than we do today.
pageinspect is useful, too, but it seems to deal mostly with pages, so
I'm not sure it's a natural substitute for something like this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
