Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Reviewing freeze map code
Date
Msg-id CAA4eK1JHz=OB4Ya+_1dMRqgxrKCt4LxiSyukgm3ZzuxF2ONqGA@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reviewing freeze map code  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 7, 2016 at 2:52 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund <andres@anarazel.de> wrote:
>
>
> > I'd also be ok with adding & documenting (beta release notes)
> > CREATE EXTENSION pg_visibility;
> > SELECT relname FROM pg_class WHERE relkind IN ('r', 'm') AND NOT pg_check_visibility(oid);
> > or something olong those lines.
>
> That wouldn't be too useful as-written in my book, because it gives
> you no detail on what exactly the problem was.  Maybe it could be
> "pg_check_visibility(regclass) RETURNS SETOF tid", where the returned
> TIDs are non-frozen TIDs on frozen pages.  Then I think something like
> this would work:
>
> SELECT c.oid, pg_check_visibility(c.oid) FROM pg_class WHERE relkind
> IN ('r', 't', 'm');
>

I have implemented the above function in attached patch.  Currently, it returns SETOF tupleids, but if we want some variant of same, that should also be possible.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: WIP: Data at rest encryption
Next
From: Tom Lane
Date:
Subject: Re: Re: pg9.6 segfault using simple query (related to use fk for join estimates)