| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: oauth integer overflow |
| Date: | 2026-04-23 19:05:32 |
| Message-ID: | CAOYmi+mGZ5H+k_Y-ascgK7X9snAGdBUOuc=FZRxu6gnB_mjFFQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 23, 2026 at 11:37 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> How about instead making sure that actx->authz.interval never gets big enough
> to have any chance of overflowing during either the += 5 or the * 1000? It's
> clearly ok to error out well before that...
It probably is, but I guess the approach depends on whether you prefer
checking at the time of operation, or attempting to reason about it
ahead of time in far-away code. With the latter, if additional math is
added in the future, then either the new overflow hazard gets missed,
or the ceiling gets lowered again, or the new math gets an overflow
check when the others don't. I prefer the time-of-use pattern,
personally.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2026-04-23 21:06:18 | Re: GUC parameter ACLs and physical walsender |
| Previous Message | Heikki Linnakangas | 2026-04-23 18:49:04 | Re: CheckAttributeType() forgot to recurse into multiranges |