Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY

Hi,

On 2022-08-15 19:56:40 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The easiest fix is likely to force all buffers to be forgotten at the end of
> > index_concurrently_build() or such.
> 
> Race conditions there ...

Not immediately seeing it? New reads from disk will read valid data.

But I agree, it's a shitty approach.


> > I don't immediately see a nicer way to fix
> > this, we can't just lock the new index relation exclusively.
> 
> Why not?  If the index isn't valid yet, other backends have zero
> business touching it.  I'd think about taking an exclusive lock
> to start with, and releasing it (downgrading to a non-exclusive
> lock) once the index is valid enough that other backends can
> access it, which would be just before we set pg_index.indisready
> to true.

I'm afraid we'd start blocking in quite a few places, both inside and outside
of core PG. E.g. ExecOpenIndices(), ExecInitPartitionInfo(),
calculate_toast_table_size(), ... will open all indislive indexes, even if not
indisready.


> Basically, this is to enforce the previously-implicit contract
> that other sessions won't touch the index too soon against
> careless superusers.

I suspect this isn't restricted to superusers, fwiw. E.g. pg_prewarm doesn't()
require superuser.

Greetings,

Andres Freund