]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.
authorAndres Freund <andres@anarazel.de>
Wed, 1 May 2019 00:45:32 +0000 (17:45 -0700)
committerAndres Freund <andres@anarazel.de>
Wed, 1 May 2019 00:45:32 +0000 (17:45 -0700)
commit63c6a24ae4d66422417dfa89527824a7b4b4ceb4
tree34996f2c7ec1198be0cbdb4b2b1300a6dad6ab0c
parentd264bb51c5ad12708394725eab14dae7be5c0b59
Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.

The tests turn out to cause deadlocks in some circumstances. Fairly
reproducibly so with -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE.  Some of the deadlocks may be hard to fix
without disproportionate measures, but others probably should be fixed
- but not in 12.

We discussed removing the new tests until we can fix the issues
underlying the deadlocks, but results from buildfarm animal
markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there
might be a more severe, as of yet undiagnosed, issue (including on
stable branches) with reindexing catalogs. The failure is:
ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes
Therefore it seems advisable to keep the tests.

It's not certain that running the tests in isolation removes the risk
of deadlocks. It's possible that additional locks are needed to
protect against a concurrent auto-analyze or such.

Per discussion with Tom Lane.

Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
Backpatch: 9.4-, like 3dbb317d3
src/test/regress/expected/create_index.out
src/test/regress/expected/reindex_catalog.out [new file with mode: 0644]
src/test/regress/parallel_schedule
src/test/regress/serial_schedule
src/test/regress/sql/create_index.sql
src/test/regress/sql/reindex_catalog.sql [new file with mode: 0644]