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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Toru SHIMOGAKI <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] BUG #2704: pg_class.relchecks overflow problem
Date: 2006-11-12 04:28:50
Message-ID: 20878.1163305730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-patches

Toru SHIMOGAKI <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Roman Shterenzon 2006-11-12 11:10:41 BUG #2754: cache lookup failed for function 8470229
Previous Message Simon Riggs 2006-11-11 08:17:54 Re: [PERFORM] BUG #2737: hash indexing large table fails, while btree of same index works

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Lindner 2006-11-12 09:27:26 Re: Giving up multiple postmaster + RPM issue
Previous Message Tom Lane 2006-11-12 04:06:41 Re: [HACKERS] server process (PID 1188) exited with exit code -1073741819, 8.2 beta1

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-12 16:03:49 Re: [PATCHES] WIP 2 interpreters for plperl
Previous Message Brendan Jurd 2006-11-11 02:38:13 Re: [HACKERS] Indicate disabled triggers in \d