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
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 |