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
|
Список | 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 по дате отправления: