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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table
Дата
Msg-id 1541688.1708893428@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table