From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: sk@zsrv.org, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Subject: Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY
Date: Mon, 15 Aug 2022 19:56:40 -0400
Message-ID: <996031.1660607800@sss.pgh.pa.us> (raw)
In-Reply-To: <20220815233924.5jlus3ukkqmmts5g@awork3.anarazel.de>
References: <17568-ef121b956ec1559c@postgresql.org>
<20220815233924.5jlus3ukkqmmts5g@awork3.anarazel.de>
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 ...
> 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.
Basically, this is to enforce the previously-implicit contract
that other sessions won't touch the index too soon against
careless superusers.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, michael.paquier@gmail.com, melanieplageman@gmail.com
Subject: Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY
In-Reply-To: <996031.1660607800@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox