On 29.10.24 07:51, Michael Paquier wrote:
On Tue, Oct 29, 2024 at 07:38:36AM +0100, Peter Eisentraut wrote:
I think it could be useful to set up some better test coverage for various
things overflowing signed integer maximums. For example, maybe you could
hack initdb to advance the OID counter
On 27.10.24 04:59, Andy Fan wrote:
I haven't found anything that is a really serious bug, but I imagine you
could run into trouble in various ways when you exceed the INT_MAX
value. But then again, if you use up INT_MAX WAL timelines, you
probably have other problems. ;-)
Me too, just that want
On Tue, Oct 29, 2024 at 07:38:36AM +0100, Peter Eisentraut wrote:
> I think it could be useful to set up some better test coverage for various
> things overflowing signed integer maximums. For example, maybe you could
> hack initdb to advance the OID counter to INT32_MAX+1 or thereabouts and run
>
Peter Eisentraut writes:
Hi,
> On 2020-10-29 22:37, Thomas Munro wrote:
>> There're probably mostly harmless, being mostly error and debug
>> messages and the like, and considering that eg OID parsing tolerates
>> negative numbers when reading them back in, but for what it's worth:
>> GCC compla
On Tue, Nov 10, 2020 at 4:25 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > 1. enums are unsigned by default in gcc, so all those internal error
> > messages "unrecognized blah kind: %d" need to be changed to %u.
>
> Do we have reason to think that that is true in every C compiler?
> My own pr
Peter Eisentraut writes:
> 1. enums are unsigned by default in gcc, so all those internal error
> messages "unrecognized blah kind: %d" need to be changed to %u.
Do we have reason to think that that is true in every C compiler?
My own preference for this would be to leave the messages as-is
and
