On Mon, May 23, 2022 at 10:07:44AM +0200, Alvaro Herrera wrote:
> I think if this is a big enough deal (and I think it may be) then IMO we
> should revert as you suggest, make an out-of-schedule release, and then
> I can take some time to investigate in more depth and see if the feature
> can be salvaged.
>
> OTOH if we think an out-of-schedule release is not warranted, then
> reverting right now is not useful; we can make a decision about that
> closer to the next minor release, once we've had time to see if the bug
> can be fixed in some other way that doesn't break the whole feature.
The annoying part is that this can cause silent corruptions for
indexes created with REINDEX and CIC, so most users won't know about
the failure until they see that their application is broken. And we
are just talking about a btree index here, other index AMs may be
similarly impacted. So that's rather bad IMHO :/
It seems to me that the problem is around the wait phase after the
validation, where the computation of limitXmin coming from the
snapshot used for the validation ignores now the impact of VACUUM,
hence impacting the timing when the index can be safely used. It also
looks like it is possible to build an isolation test, where we use a
transaction with a snapshot older than the REINDEX to force it to
wait in the first WaitForOlderSnapshots() call.
--
Michael