From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: preserving forensic information when we freeze |
Date: | 2013-12-20 02:22:02 |
Message-ID: | 20131220022202.GO11006@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 do that 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 incredibly handy 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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-12-20 03:07:25 | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Previous Message | Gregory Smith | 2013-12-20 02:18:10 | Re: row security roadmap proposal |