From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with
 expression index over select from table
In-reply-to: <18363-e3598a5a572d0699@postgresql.org>
References: <18363-e3598a5a572d0699@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 25 Feb 2024 18:00:01 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1541687.1708893428.1@sss.pgh.pa.us>
Date: Sun, 25 Feb 2024 15:37:08 -0500
Message-ID: <1541688.1708893428@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1541688.1708893428%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t(i INT PRIMARY KEY);
> CREATE FUNCTION f(i int) RETURNS int IMMUTABLE LANGUAGE SQL
>   RETURN (SELECT i FROM t WHERE i = $1);
> CREATE INDEX ON t(f(i));
> INSERT INTO t VALUES (1);
> REINDEX INDEX t_f_idx;

> triggers an assertion failure with the stack trace:
> ...

> With a non-assertion-enabled build it fails with:
> ERROR:  could not read block 0 in file "base/16384/16392": read only 0 of
> 8192 bytes
> CONTEXT:  SQL function "f" during startup

> Surely, such an index will not work correctly anyway, but may be it makes
> sense to replace that Assert with ereport(ERROR).

Yeah, I guess so.  We periodically get reports of the non-assert
failure, and this would let us issue a more on-point error message.
I'm slightly worried about the extra cost, but typically
pendingReindexedIndexes should be empty or at least short, so it's
probably negligible.

			regards, tom lane