From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Kevin Bloch <kev@codingthat.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: maximum for auto_explain.log_min_duration doesn't seem to make
 sense
In-reply-to: 
 <CAKFQuwaPyFHN=cmEhOYdd2R5daZP2Wn0og9M8BEPE5k_tuQYjA@mail.gmail.com>
References: <8ea82d7e-cb78-8e05-0629-73aa14d2a0ca@codingthat.com>
 <CAKFQuwaPyFHN=cmEhOYdd2R5daZP2Wn0og9M8BEPE5k_tuQYjA@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Fri, 23 Feb 2018 12:02:58 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <16574.1519413959.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Fri, 23 Feb 2018 14:25:59 -0500
Message-ID: <16575.1519413959@sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Feb 23, 2018 at 11:34 AM, Kevin Bloch <kev@codingthat.com> wrote:
>> According to https://dba.stackexchange.com/a/198429/28774 , this setting
>> maxes out at INT_MAX / 1000, but since it's never multiplied by 1000 or any
>> other number, it seems it should perhaps just be INT_MAX

> ​I suspect that the counter to which that value is being compared also
> wants to be an INT and if one checks for "val > INT_MAX" then val cannot be
> restricted to an integer (and since we are capturing time we need some
> unknown buffer).

No, a look at the code shows that it's being compared to a double.
So there's no practical problem with increasing that GUC's limit to
INT_MAX.  As to whether it's worth doing, the existing limit is equivalent
to ~35 minutes if I did the math right.  I can barely imagine that anyone
would want to set auto_explain.log_min_duration higher than that, but
maybe in some huge data warehouse environment it'd make sense.  Anyway,
I notice that the core backend's log_min_duration GUC, which is also
measured in ms, is allowed to go up to INT_MAX; so it seems a bit
inconsistent that this one isn't.

In short, seems like a valid complaint to me.

			regards, tom lane