Re: found xmin x from before relfrozenxid y

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: found xmin x from before relfrozenxid y
Дата
Msg-id 20181022010105.v4wzvjhpqhmlz2zu@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: found xmin x from before relfrozenxid y  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hi,

On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
> =?UTF-8?Q?Johannes_Gra=c3=abn?= <johannes@selfnet.de> writes:
> > after upgrading to version 11, I see the error pattern "found xmin x
> > from before relfrozenxid y" in different databases on different hosts.
> > From https://www.postgresql.org/docs/10/static/release-10-3.html, I
> > learned that this was an error caused by pg_upgrade, which apparently
> > had been fixed in 10.3. This page also states that refreshing the
> > affected materialized view non-concurrently would fix the problem.
> > My question is now how to infer the affected materialized view from the
> > error message. Is there a way to tell which one to refresh from the xmin
> > or relfrozenxid value?
> 
> No :-(.  I wonder why in the world we didn't make that error message
> include the relation and block number the tuple was found in.

Because it was a really complicated bugfix already, I don't think the
answer is more complicated than that.


> (Well, I see the short answer: the code layer throwing the error
> doesn't know.  But that could be fixed easily enough.)

I wonder if the better approach wouldn't be to add an errcontext for
vaccuum, where continually update the block number etc. Theres plenty of
different sources of corruption that'd potentially cause debug messages
or errors, and that should get most of them.

Greetings,

Andres Freund


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

Предыдущее
От: legrand legrand
Дата:
Сообщение: Re: no queryId in post_parse_analyze hook when row is locked
Следующее
От: David Rowley
Дата:
Сообщение: Re: Help with list partitioning on expression