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