Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Amul Sul <sulamul(at)gmail(dot)com>
Cc: Neha Sharma <neha(dot)sharma(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb
Date: 2021-03-22 09:32:52
Message-ID: CA+HiwqE11ZkfAMVhV3KPAeLf5d9vru-yc6CY-u1WOFBtXKdhfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 22, 2021 at 5:26 PM Amul Sul <sulamul(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-03-22 09:44:49 RE: should INSERT SELECT use a BulkInsertState?
Previous Message Dilip Kumar 2021-03-22 09:18:02 Re: [HACKERS] Custom compression methods