Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Дата
Msg-id CAH2-WzmPJVPZoCm1tpSnJBN6S4fhJsVKCRRUwCJJJ9GMvsmPUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: found xmin from before relfrozenxid on pg_catalog.pg_authid  (Jeremy Finzel <finzelj@gmail.com>)
Ответы Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Список pgsql-general
On Mon, Mar 19, 2018 at 1:55 PM, Jeremy Finzel <finzelj@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


В списке pgsql-general по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: STRING_AGG and GROUP BY
Следующее
От: Jeremy Finzel
Дата:
Сообщение: Re: found xmin from before relfrozenxid on pg_catalog.pg_authid