Parallel index creation does not properly cleanup after error
От | David Rowley |
---|---|
Тема | Parallel index creation does not properly cleanup after error |
Дата | |
Msg-id | CAKJS1f91kq1wfYR8rnRRfKtxyhU2woEA+=whd640UxMyU+O0EQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Parallel index creation does not properly cleanup after error
|
Список | pgsql-hackers |
Hi, I've just stumbled on a bug in the parallel reindexing code. Example: -- force parallel index creation set parallel_tuple_cost = 0; set parallel_setup_cost = 0; set min_parallel_table_scan_size = '0MB'; set min_parallel_index_scan_size = '0kB'; -- example (from the regression tests) CREATE TABLE mvtest_foo(a, b) AS VALUES(1, 10); CREATE MATERIALIZED VIEW mvtest_mv AS SELECT * FROM mvtest_foo; CREATE UNIQUE INDEX ON mvtest_mv(a); INSERT INTO mvtest_foo SELECT * FROM mvtest_foo; REFRESH MATERIALIZED VIEW mvtest_mv; ERROR: cannot modify reindex state during a parallel operation Due to the failure during the index build, it appears that the PG_TRY/PG_CATCH block in reindex_relation() causes the reindex_index() to abort and jump out to the catch block. Here there's a call to ResetReindexPending(), which complains as we're still left in parallel mode from the aborted _bt_begin_parallel() call which has called EnterParallelMode(), but not managed to make it all the way to _bt_end_parallel() (called from btbuild()), where ExitParallelMode() is normally called. Subsequent attempts to refresh the materialized view result in an Assert failure in list_member_oid() REFRESH MATERIALIZED VIEW mvtest_mv; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. I've not debugged that, but I assume it's because pendingReindexedIndexes is left as a non-empty list but has had its memory context obliterated due to the previous query having ended. The comment in the following fragment is not well honored by the ResetReindexPending() since it does not clear the list if there's an error. PG_CATCH(); { /* Make sure list gets cleared on error exit */ ResetReindexPending(); PG_RE_THROW(); } static void ResetReindexPending(void) { if (IsInParallelMode()) elog(ERROR, "cannot modify reindex state during a parallel operation"); pendingReindexedIndexes = NIL; } A perhaps simple fix would be just to have ResetReindexPending() only reset the list to NIL again and not try to raise any error. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: