Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 29 Feb 2024 14:46:07 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with
 expression index over select from table
Message-ID: <ZeAaH7GQobcZync0@paquier.xyz>
References: <18363-e3598a5a572d0699@postgresql.org>
 <1541688.1708893428@sss.pgh.pa.us>
 <ZdvF3lD5W9IySEa8@paquier.xyz>
 <1660000.1708902298@sss.pgh.pa.us>
 <6ac7f5aa-2d19-bde9-057a-3cb1e175bde6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vzemheTQX2dZSVfl"
Content-Disposition: inline
In-Reply-To: <6ac7f5aa-2d19-bde9-057a-3cb1e175bde6@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZeAaH7GQobcZync0%40paquier.xyz>
Precedence: bulk


--vzemheTQX2dZSVfl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2024 at 09:00:01AM +0300, Alexander Lakhin wrote:
> It looks like currentlyReindexedIndex =3D=3D 0 in this case, so
> ReindexIsProcessingIndex() doesn't guard against get_relation_info() ->
> _bt_getrootheight() -> _bt_getbuf() -> ReadBuffer() -> ... -> mdread().

Fun.  The concurrent case is actually able to work because it looks
like the basic definition of the relation exists with its relfilenode.

I was looking at that, and it seems to me that the point is not that
the index is being reindexed; the point is that we want to prevent
access to the index itself while it being built.  And that's something
that can happen for a reindex as much as a new index.  It would be
possible to paint an equivalent of SetReindexProcessing() in
index_create() for index_build() where a trace of the index OID
getting built is kept around, and it would be possible to trigger the
same  error as when doing a reindex.  Hence, if we were to do that,
the current ReindexIs*() routines maintaining the list of the indexes=20
being built across transaction states are a bit misnamed, and the
error messages would be partially incorrect.

I am not sure if this is worth bothering beyond HEAD, or worth
bothering at all, but seeing 940489b467 it looks like we do bother
even for stable branches.
--
Michael

--vzemheTQX2dZSVfl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmXgGh8ACgkQnvQgOdby
QH3rLA//exZaWN6ypD48wSPNsGt2hSnSXeExSDs9SOuWztTHV0DW+LVUlYMf8737
ITsvj/I58mJCE+LUslBTMwQKwhG6oDhXanV/TH2fCP9AH0IeEUngHOcFMBj/Xq2v
uYMPBe9SZbXpfbKu4LQK9ad77HmZ1FfZuIvAJuByozayvUUbBhUqLdnlkcEsS9U8
cYGXr1Dlmn/CvkFk6tSq0C0WJfBsk64LJPkXtCa6J9Y8hQx/ceCmNx3KdxX5jyM+
4MDYxTLOMTVF55Fm9JmYm45ZJ42k7ip9Nj7COgh7QN+1oeo1ppwMQ212E50BGTf2
xpbi79Z6ISs1gJ+7oJ7QMVmXJCvoHnz2OGiTWxiQ931XEJ9OoB5DgqLuDqK6+skp
LIY4jZ1uieBMpIE2emVbHh9UQKIBs7q6yr8NVRi2hS81TNLxI7WQkBf5DE7Kz1xJ
ThU47Lg0Sm6VS9iifH63p+A6WBkBc1tBi6t2JMZ/YIugEf0SOqpXF+eyEk7IvjfG
sfDnkrGdRtXzglfahC+lsWvuoXPQA033UNTeVv0/eDB1a1YauDUXYG2uHQQyqIoB
Rm5U1/XjNTmpsG1XvOPGEmQIDGrH2EzmTVvemoefNTtEyqKhT6sfr/Aze2lcSnDO
VasWR1RzylCqB4N7jnTr5jB8rthYy/LpRwnvKVhl5voxDD8atWQ=
=PUGv
-----END PGP SIGNATURE-----

--vzemheTQX2dZSVfl--