Thread: Re: [PATCHES] [BUGS] BUG #2704: pg_class.relchecks overflow problem

Toru SHIMOGAKI <shimogaki.toru@oss.ntt.co.jp> writes:
> +         if (numchecks == 0x7FFF)
> +             ereport(ERROR,
> +                     (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> +               errmsg("cannot have more than 2^15-1 checks in a table")));

While there's not anything wrong with this proposed patch in itself,
I have to admit that I don't see the point.  There are probably
thousands of places in the backend where we increment an integer
value without checking for overflow.  Is this one particularly more
likely to occur than other ones, or does it have worse consequences
than other ones?  I don't see a security issue here (since the backend
doesn't crash) and I also don't see that this limit is close enough to
real practice to be important to guard against.

It's not that the check imposes any significant addition in code space
or runtime, but what it *would* impose is a nontrivial extra burden on
our message translators.  Scale this up by a few hundred or thousand
equally unlikely conditions with their own error messages, and we'd
have a revolt ...

            regards, tom lane

Tom Lane wrote:
> While there's not anything wrong with this proposed patch in itself,
> I have to admit that I don't see the point.

The points are:
1. It is just unpleasant to leave the overflow.
2. It is not easy for users to understand what they should do when they
encounter the error message. At least users can't understand that it is because
of the upper limit:

 ERROR: unexpected constraint record found for rel test_a


I haven't found such a case in real practice. But I think the limit will be a
little closer than that is now, because constraint exclusion is expanded for
UPDATE/DELETE in 8.2 and the opportunity of using check constraint will increase
 . So I investigated the upper limit and found it.

By the way, as you said, it would impose an extra burden on message translators
and I can understand your opinion. But will it lead directly to the reason that
we don't fix it?

Best regards,

--
Toru SHIMOGAKI<shimogaki.toru@oss.ntt.co.jp>