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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Noah Misch <noah@leadboat.com>,
Neha Sharma <neha.sharma@enterprisedb.com>,
Amit Langote <amitlangote09@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-07-06T17:36:29Z
Lists: pgsql-hackers
Amul Sul <sulamul@gmail.com> writes: > On Tue, Apr 20, 2021 at 6:59 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: >> I don't mind RelationGetSmgr(index)->smgr_rnode alone or >> &variable->member alone and there's not the previous call to >> RelationGetSmgr just above. How about using a temporary variable? >> >> SMgrRelation srel = RelationGetSmgr(index); >> smgrwrite(srel, ...); >> log_newpage(srel->..); > Understood. Used a temporary variable for the place where > RelationGetSmgr() calls are placed too close or in a loop. [ squint... ] Doesn't this risk introducing exactly the sort of cache-clobber hazard we're trying to prevent? That is, the above is not safe unless you are *entirely* certain that there is not and never will be any possibility of a relcache flush before you are done using the temporary variable. Otherwise it can become a dangling pointer. The point of the static-inline function idea was to be cheap enough that it isn't worth worrying about this sort of risky optimization. Given that an smgr function is sure to involve some kernel calls, I doubt it's worth sweating over an extra test-and-branch beforehand. So where I was hoping to get to is that smgr objects are *only* referenced by RelationGetSmgr() calls and nobody ever keeps any other pointers to them across any non-smgr operations. 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