| From: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge() |
| Date: | 2023-09-28 09:01:14 |
| Message-ID: | CAKZiRmxEzCAc9C8YTXwo7C0EzqUrhuqsTSiciEnLw5fCh-hCFA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 28, 2023 at 12:53 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote:
> > I don't think going for size_t is a viable path for fixing this. I'm pretty
> > sure the initial patch would trigger a type mismatch from guc_tables.c - we
> > don't have infrastructure for size_t GUCs.
>
> Nothing marked as PGDLLIMPORT uses size_t in the tree currently, FWIW.
>
> > Perhaps we ought to error out (in BackendStatusShmemSize() or such) if
> > pgstat_track_activity_query_size * MaxBackends >= 4GB?
>
> Yeah, agreed that putting a check like that could catch errors more
> quickly.
Hi,
v3 attached. I had a problem coming out with a better error message,
so suggestions are welcome. The cast still needs to be present as per
above suggestion as 3GB is still valid buf size and still was causing
integer overflow. We just throw an error on >= 4GB with v3.
-J.
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Introduce-memory-limit-for-BackendActivityBuffer-.patch | application/octet-stream | 2.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-09-28 09:02:01 | Re: [PoC] pg_upgrade: allow to upgrade publisher node |
| Previous Message | Amit Kapila | 2023-09-28 08:57:15 | Re: [PoC] pg_upgrade: allow to upgrade publisher node |