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
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 |