Feedback-ID: ia2694551:Fastmail
Date: Wed, 9 Oct 2024 12:59:20 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>,
	jian he <jian.universality@gmail.com>
Subject: Re: overflow bug for inhcounts
Message-ID: <202410091059.oyl22p2w5kie@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1938142.1728406028@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202410091059.oyl22p2w5kie%40alvherre.pgsql>
Precedence: bulk

On 2024-Oct-08, Tom Lane wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > ... This is because ColumnDef->inhcount is a 32-bit int, but
> > Form_pg_attribute->attinhcount is int16, so we didn't break the overflow
> > test for ColumnDef inhcount, but attinhcount has overflowed during
> > assignment.
> 
> Ugh ... somebody's ancient oversight there.  Or maybe attinhcount
> was once int32, and we narrowed it for space reasons?

Yeah, both attinhcount and coninhcount were narrowed in 90189eefc1e1
during REL_16_STABLE development, so it's a relatively new problem.

> > From branch master, I propose we change those two members to int16
> > (ColumnDef->inhcount and CookedConstraint->inhcount) to make those
> > counters consistently use the same type; and then use
> > pg_add_s16_overflow() instead of ++ for the increments, as in the
> > attached patch.  With this patch, the child table creation fails as
> > expected ("too many inheritance parents").
> 
> +1.  I didn't check if there were any other places to touch, but
> this looks like a good solution for master.

Thanks for looking.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La conclusión que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusión de ellos" (Tanenbaum)