Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6
Date: 2019-04-26 03:14:39
Message-ID: 20190426031439.GC1904@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-04-26 03:37:50 Re: pg_waldump and PREPARE
Previous Message Michael Paquier 2019-04-26 03:05:37 Re: "Routine Reindexing" docs should be updated to reference REINDEX CONCURRENTLY