Re: REINDEX INDEX results in a crash for an index of pg_class since9.6

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
Дата
Msg-id 20190426031439.GC1904@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Apr 25, 2019 at 11:32:21AM -0400, Tom Lane wrote:
> What you have to do to get it to crash is to ensure that
> RelationSetNewRelfilenode's update of pg_class will be a non-HOT
> update.  You can try to set that up with "vacuum full pg_class"
> but it turns out that that tends to leave the pg_class entries
> for pg_class's indexes in the last page of the relation, which
> is usually not totally full, so that a HOT update works and the
> bug doesn't manifest.

Indeed, I can see that the update difference after and before the
commit.  This could have blowed up on basically anything when
bisecting.  Changing the page size would have given something else
perhaps..

> As for an actual fix, I tried just moving reindex_index's
> SetReindexProcessing call from where it is down to after
> RelationSetNewRelfilenode, but that isn't sufficient:
>
> regression=# reindex index pg_class_relname_nsp_index;
> psql: ERROR:  could not read block 3 in file "base/16384/41119":
> read only 0 of 8192 bytes

Yeah, that's one of the first things I tried as well when first
looking at the problem.  Turns out it is not that simple.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: "Routine Reindexing" docs should be updated to reference REINDEXCONCURRENTLY
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_waldump and PREPARE