Thread: Re: overflow bug for inhcounts

Re: overflow bug for inhcounts

From
Tom Lane
Date:
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?

> 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.

> In stable branches, I see two possible approaches: we could use the same
> ptach as master (but add another int16 to the struct as padding, to
> avoid changing the struct layout),

That would not preserve ABI on machines with the wrong endianness.

> or, less intrusive, we could leave
> that alone and instead change the "overflow" after the addition to test
> inhcount > PG_INT16_MAX instead of < 0.  Or we could leave it all alone.

On the whole I'd leave it alone in back branches.  Nobody who's not
intentionally trying to break their table will hit this.

> (I'm not terribly enthused about adding a test that creates a child
> table with 2^16 parents, because of the added runtime -- on my machine
> the scripts above take about 4 seconds.)

Agreed, too expensive for the value.

            regards, tom lane



Re: overflow bug for inhcounts

From
Alvaro Herrera
Date:
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)