Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Noah Misch <noah@leadboat.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Neha Sharma <neha.sharma@enterprisedb.com>, Amul Sul <sulamul@gmail.com>, Amit Langote <amitlangote09@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-23T15:29:24Z
Lists: pgsql-hackers 
I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> One bisect later, the winner is:
>> commit: 3d351d916b20534f973eda760cde17d96545d4c4
>> author: Tom Lane <tgl@sss.pgh.pa.us>
>> date: Sun, 30 Aug 2020 12:21:51 -0400
>> Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.

> I think that's an artifact.  That commit didn't touch anything related to
> relation opening or closing.  What it could have done, though, is change
> CLUSTER's behavior on this empty table from use-an-index to use-a-seqscan,
> thus causing us to follow the buggy code path where before we didn't.

On closer inspection, I believe the true culprit is c6b92041d,
which did this:

 	 */
 	if (RelationNeedsWAL(state->rs_new_rel))
-		heap_sync(state->rs_new_rel);
+		smgrimmedsync(state->rs_new_rel->rd_smgr, MAIN_FORKNUM);
 
 	logical_end_heap_rewrite(state);

heap_sync was careful about opening rd_smgr, the new code not so much.

I read the rest of that commit and didn't see any other equivalent
bugs, but I might've missed something.

			regards, tom lane

Commits

  1. Replace RelationOpenSmgr() with RelationGetSmgr().

  2. Avoid possible crash while finishing up a heap rewrite.

  3. Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.