On Mon, Apr 13, 2020 at 04:22:26PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> I'd much rather see this throw an assertion than the current
>> behaviour. But I'm wondering if there's a chance we can throw an error
>> in non-assert builds without adding too much complexity to the error
>> pat
Andres Freund writes:
> On 2020-04-11 10:54:49 -0400, Tom Lane wrote:
>> I guess you could make them PANICs, but it would be an option that nobody
>> could possibly want to have enabled in anything resembling production.
>> So I"m kind of -0.5 on making --enable-cassert do it automatically.
>> Alt
Hi,
On 2020-04-11 10:54:49 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > How about a compile-time option to turn all the warnings in resowner.c
> > into errors? This could be enabled automatically by --enable-cassert,
> > similar to other defines that that option enables.
>
> [ itch..
Peter Eisentraut writes:
> How about a compile-time option to turn all the warnings in resowner.c
> into errors? This could be enabled automatically by --enable-cassert,
> similar to other defines that that option enables.
[ itch... ] Those calls occur post-commit; throwing an error there
is
On Sat, Apr 11, 2020 at 10:09:59AM +0200, Peter Eisentraut wrote:
> I just fixed a relcache leak that I accidentally introduced (5a1d0c9925).
> Because it was a TAP test involving replication workers, you don't see the
> usual warning anywhere unless you specifically check the log files manually.
>
I just fixed a relcache leak that I accidentally introduced
(5a1d0c9925). Because it was a TAP test involving replication workers,
you don't see the usual warning anywhere unless you specifically check
the log files manually.
How about a compile-time option to turn all the warnings in resowne
