On Mon, Mar 19, 2018 at 4:12 PM, Peter Geoghegan <p...@bowt.ie> wrote:

> On Mon, Mar 19, 2018 at 1:55 PM, Jeremy Finzel <finz...@gmail.com> wrote:
> > @Peter :
> >
> > staging=# SELECT * FROM page_header(get_raw_page('pg_authid', 7));
> >       lsn       | checksum | flags | lower | upper | special | pagesize |
> > version | prune_xid
> > ----------------+----------+-------+-------+-------+--------
> -+----------+---------+-----------
> >  262B4/10FDC478 |        0 |     1 |   304 |  2224 |    8192 |     8192 |
> > 4 |         0
> > (1 row)
>
> Thanks.
>
> That looks normal. I wonder if the contents of that page looks
> consistent with the rest of the table following manual inspection,
> though. I recently saw system catalog corruption on a 9.5 instance
> where an entirely different relation's page ended up in pg_attribute
> and pg_depend. They were actually pristine index pages from an
> application index. I still have no idea why this happened.
>
> This is very much a guess, but it can't hurt to check if the contents
> of the tuples themselves are actually sane by inspecting them with
> "SELECT * FROM pg_authid". heap_page_items() doesn't actually care
> about the shape of the tuples in the page, so this might have been
> missed.
>
> --
> Peter Geoghegan
>

The data all looks fine.  I even forced the index scan on both indexes
which also looks fine.

Thanks,
Jeremy

Reply via email to