Re: PSQL error: total cell count of XXX exceeded

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Hongxu Ma <interma(at)outlook(dot)com>, Jelte Fennema <postgres(at)jeltef(dot)nl>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PSQL error: total cell count of XXX exceeded
Date: 2023-11-20 22:29:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I think we're bound to hit this limit at some point in the future, and
> it seems easy enough to solve. I propose the attached, which is pretty
> much what Hongxu last submitted, with some minor changes.

This bit needs more work:

- content->cells = pg_malloc0((ncolumns * nrows + 1) * sizeof(*content->cells));
+ total_cells = (int64) ncolumns * nrows;
+ content->cells = pg_malloc0((total_cells + 1) * sizeof(*content->cells));

You've made the computation of total_cells reliable, but there's
nothing stopping the subsequent computation of the malloc argument
from overflowing (especially on 32-bit machines). I think we need
an explicit test along the lines of

if (total_cells >= SIZE_MAX / sizeof(*content->cells))
throw error;

(">=" allows not needing to add +1.)

Also, maybe total_cells should be uint64? We don't want
negative values to pass this test. Alternatively, add a separate
check that total_cells >= 0.

It should be sufficient to be paranoid about this in printTableInit,
since after that we know the product of ncolumns * nrows isn't
too big.

The rest of this passes an eyeball check.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-11-20 22:48:27 Re: PANIC serves too many masters
Previous Message Jeff Davis 2023-11-20 22:27:34 Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }