Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amul Sul <sulamul@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Noah Misch <noah@leadboat.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Neha Sharma <neha.sharma@enterprisedb.com>,
Amit Langote <amitlangote09@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-24T14:39:42Z
Lists: pgsql-hackers
Amul Sul <sulamul@gmail.com> writes:
> On Tue, Mar 23, 2021 at 8:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> On closer inspection, I believe the true culprit is c6b92041d,
>> which did this:
>> - heap_sync(state->rs_new_rel);
>> + smgrimmedsync(state->rs_new_rel->rd_smgr, MAIN_FORKNUM);
>> heap_sync was careful about opening rd_smgr, the new code not so much.
> So we also need to make sure of the
> RelationOpenSmgr() call before smgrimmedsync() as proposed previously.
I wonder if we should try to get rid of this sort of bug by banning
direct references to rd_smgr? That is, write the above and all
similar code like
smgrimmedsync(RelationGetSmgr(state->rs_new_rel), MAIN_FORKNUM);
where we provide something like
static inline struct SMgrRelationData *
RelationGetSmgr(Relation rel)
{
if (unlikely(rel->rd_smgr == NULL))
RelationOpenSmgr(rel);
return rel->rd_smgr;
}
and then we could get rid of most or all other RelationOpenSmgr calls.
This might create more code bloat than it's really worth, but
it'd be a simple and mechanically-checkable scheme.
regards, tom lane
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