Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: exclusion(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table
Date: 2024-02-25 20:37:08
Message-ID: 1541688.1708893428@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2024-02-25 22:57:34 Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table
Previous Message PG Bug reporting form 2024-02-25 18:00:01 BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table