Re: POC: make mxidoff 64 bits

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-12-14 22:55:36
Message-ID: 1827755.1765752936@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> Ok, I have pushed this. Thanks!

Coverity is unhappy about this bit:

/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_upgrade/multixact_read_v18.c: 282 in GetOldMultiXactIdSingleMember()
276 if (!TransactionIdIsValid(*xactptr))
277 {
278 /*
279 * Corner case 2: we are looking at unused slot zero
280 */
281 if (offset == 0)
>>> CID 1676077: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "continue;".
282 continue;
283
284 /*
285 * Otherwise this is an invalid entry that should not be

It sees the earlier test for offset == 0, and evidently is assuming
that the loop's "offset++" will not wrap around. Now I think that
the point of this check is exactly that "offset++" could have wrapped
around, but the commentary is not so clear that I'm certain this is a
false positive. If that is the intention, what do you think of
rephrasing this comment as "we have wrapped around to unused slot
zero"?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-12-14 23:02:53 Re: Trying out read streams in pgvector (an extension)
Previous Message Tom Lane 2025-12-14 22:12:25 Re: Optimization of partial index creation for a new column