Re: [PATCH] work_mem calculation possible overflow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] work_mem calculation possible overflow
Date: 2013-12-29 01:57:54
Message-ID: 30214.1388282274@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I was just looking through a few of the warnings flagged up by PVS Studio.
> I found some warnings around some calculations that were doing work_mem *
> 1024L and comparing that to a double. On windows 64 sizeof(long) is 4 bytes.
> Currently work_mem's maximum value is INT_MAX / 1024, so this should not
> overflow on windows 64 at the moment, but perhaps if work_mem's maximum is
> raised in the future then it will. In any case the L suffix on 1024 to
> widen the type here just seems a bit wrong giving that postgresql supports
> platforms where sizeof(int) and sizeof(long) is the same.

This is not a bug. Note the limitation on the allowed range of work_mem
in guc.c; that's designed precisely to ensure that work_mem * 1024L will
not overflow a long. That's perhaps a bit klugy, but if we wanted to
remove that assumption we'd have to touch far more places than what you
have done here, and most of them would require much uglier changes.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-12-29 03:36:19 pgcrypto missing header file inclusions
Previous Message Peter Eisentraut 2013-12-29 01:55:24 Re: Fix typo in src/backend/utils/mmgr/README