Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Amul Sul <sulamul@gmail.com>
Cc: Neha Sharma <neha.sharma@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-22T09:32:52Z
Lists: pgsql-hackers
On Mon, Mar 22, 2021 at 5:26 PM Amul Sul <sulamul@gmail.com> wrote: > In heapam_relation_copy_for_cluster(), begin_heap_rewrite() sets > rwstate->rs_new_rel->rd_smgr correctly but next line tuplesort_begin_cluster() > get called which cause the system cache invalidation and due to CCA setting, > wipe out rwstate->rs_new_rel->rd_smgr which wasn't restored for the subsequent > operations and causes segmentation fault. > > By calling RelationOpenSmgr() before calling smgrimmedsync() in > end_heap_rewrite() would fix the failure. Did the same in the attached patch. That makes sense. I see a few commits in the git history adding RelationOpenSmgr() before a smgr* operation, whenever such a problem would have been discovered: 4942ee656ac, afa8f1971ae, bf347c60bdd7, for example. I do wonder if there are still other smgr* operations in the source code that are preceded by operations that would invalidate the SMgrRelation that those smgr* operations would be called with. For example, the smgrnblocks() in gistBuildCallback() may get done too late than a corresponding RelationOpenSmgr() on the index relation. -- Amit Langote EDB: http://www.enterprisedb.com
Commits
-
Replace RelationOpenSmgr() with RelationGetSmgr().
- e21856fd652a 12.14 landed
- d4acf2eb94f3 11.19 landed
- 9a299cf7c21f 13.10 landed
- 32d5a4974c81 14.7 landed
- f10f0ae420ee 15.0 landed
-
Avoid possible crash while finishing up a heap rewrite.
- d4791ac35cb1 13.3 landed
- 9d523119fd38 14.0 landed
-
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
- 3d351d916b20 14.0 cited