From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pryzby(at)telsasoft(dot)com, pgsql-hackers(at)postgresql(dot)org, noah(at)leadboat(dot)com |
Subject: | Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation |
Date: | 2020-09-07 08:40:36 |
Message-ID: | 20200907.174036.603784943439284546.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 07 Sep 2020 13:45:28 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> The cause is that the worker had received pending-sync entry correctly
> but not never created a relcache entry for the relation using
> RelationBuildDesc. So the rd_firstRelfilenodeSubid is not correctly
> set.
>
> I'm investigating it.
Relcaches are loaded from a file with old content at parallel worker
startup. The relcache entry is corrected by invalidation at taking a
lock but pending syncs are not considered.
Since parallel workers don't access the files so we can just ignore
the assertion safely, but I want to rd_firstRelfilenodeSubid flag at
invalidation, as attached PoC patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
fix_para_reindex_on_mapped_rels_opc.patch | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-09-07 08:50:38 | Re: Online checksums verification in the backend |
Previous Message | Andrey M. Borodin | 2020-09-07 08:36:46 | Re: Yet another fast GiST build (typo) |