Re: visibility map corruption

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: visibility map corruption
Дата
Msg-id CAH2-WznQ4_-Zhz+WRGZ1mLLqTrBEOu2q37n44a2wF1RRLDn8Nw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: visibility map corruption  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: visibility map corruption
Re: visibility map corruption
Список pgsql-hackers
On Tue, Jul 6, 2021 at 11:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > ... We should just carry forward the original oldestXid.
>
> Yup.  It's a bit silly that we recognized the need to do that
> for oldestMultiXid yet not for oldestXid.

True. But at the same time it somehow doesn't seem silly at all. IME
some of the most devious bugs evade detection by hiding in plain
sight.

It looks like amcheck's verify_heapam.c functionality almost catches
bugs like this one. Something for Mark (CC'd) to consider. Does it
matter that we usually "ctx.oldest_xid = ctx.relfrozenxid", and so
usually use pg_class.relfrozenxid as our oldest_xid (and not
ShmemVariableCache->oldestXid)? In other words, could we be doing more
to sanitize ShmemVariableCache->oldestXid, especially when the
relation's pg_class.relfrozenxid happens to be set to a real XID?

> BTW, is it really necessary for copy_xact_xlog_xid to invoke pg_resetwal
> so many times?  Why can't we pass all of the update-this options in one
> call?

No opinion here.

> Who's going to do the legwork on this?

Can Bruce take care of committing the patch for this? Bruce?

This should definitely be in the next point release IMV.

-- 
Peter Geoghegan



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: trivial improvement to system_or_bail