On 5/4/17 00:21, Tom Lane wrote:
> But I'd suggest waiting till after next week's releases. If there
> are any problems induced by this, we'd be more likely to find them
> with another three months' time before it hits the wild.
done
--
Peter Eisentraut http://www.2ndQuadrant.com/
Peter Eisentraut writes:
> On 4/10/17 11:03, Peter Eisentraut wrote:
>> The release of GCC 7 is approaching [0], and the number of warnings in
>> PostgreSQL has gone up since we last looked [1]. Output attached. (My
>> version is 7.0.1 20170408.)
> GCC 7 has been released.
> Should we backpatc
On 4/10/17 11:03, Peter Eisentraut wrote:
> The release of GCC 7 is approaching [0], and the number of warnings in
> PostgreSQL has gone up since we last looked [1]. Output attached. (My
> version is 7.0.1 20170408.)
GCC 7 has been released.
Should we backpatch these warning fixes? The commit
Peter Eisentraut writes:
> On 4/12/17 00:12, Tom Lane wrote:
>> Now a human can see that saved_timeval.tv_usec must be 0..99, so
>> that the %d format item must always emit exactly 3 characters, which
>> means that really 5 bytes would be enough. I wouldn't expect a
>> compiler to know that,
On 4/12/17 00:12, Tom Lane wrote:
> The change in setup_formatted_log_time seems a bit weird:
>
> - charmsbuf[8];
> + charmsbuf[10];
>
> The associated call is
>
> sprintf(msbuf, ".%03d", (int) (saved_timeval.tv_usec / 1000));
>
> Now a human can see that s
Peter Eisentraut writes:
> Attached is a more refined patch that I propose for PG10 now. Compared
> to the previous rushed version, this one uses some more precise
> arithmetic to size some of the buffers.
Generally +1 for switching the snprintf calls to use sizeof() rather
than repeating the de
On 4/11/17 13:57, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>
>>> d) Replace most of the problematic code with psprintf() and dynamically
>>> sized buffers.
>>
>> +1 for (c) as you have it. Later we might think about selectively
>> doing (d), but it seems like more work
Tom Lane wrote:
> Peter Eisentraut writes:
> > d) Replace most of the problematic code with psprintf() and dynamically
> > sized buffers.
>
> +1 for (c) as you have it. Later we might think about selectively
> doing (d), but it seems like more work for probably not much benefit.
Yeah -- also i
Peter Eisentraut writes:
> Possible fixes:
> a) Ignore, hoping GCC will change before final release. (unlikely at
> this point)
> b) Add compiler option to disable this particular warning, worry about
> it later. (Might be an option for backpatching.)
> c) Expand the target buffer sizes until
On 2017-04-10 09:10:07 -0700, Andres Freund wrote:
> Hi,
>
> On 2017-04-10 11:03:23 -0400, Peter Eisentraut wrote:
> > The release of GCC 7 is approaching [0], and the number of warnings in
> > PostgreSQL has gone up since we last looked [1]. Output attached. (My
> > version is 7.0.1 20170408.)
Hi,
On 2017-04-10 11:03:23 -0400, Peter Eisentraut wrote:
> The release of GCC 7 is approaching [0], and the number of warnings in
> PostgreSQL has gone up since we last looked [1]. Output attached. (My
> version is 7.0.1 20170408.)
>
> Most of the issues have to do with concatenating two or mo
Hi Peter,
> c) Expand the target buffer sizes until the warning goes away. (Sample
> patch attached.)
I personally think it's a great patch. Unfortunately I don't have GCC
7.0 right now but at least it doesn't break anything on 6.3.1. Since
there is no rush I would suggest to add an entry to the
The release of GCC 7 is approaching [0], and the number of warnings in
PostgreSQL has gone up since we last looked [1]. Output attached. (My
version is 7.0.1 20170408.)
Most of the issues have to do with concatenating two or more strings of
potential size MAXPGPATH into another buffer of size MA
13 matches
Mail list logo
