Re: relcache leak warnings vs. errors

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: relcache leak warnings vs. errors
Date: 2020-04-14 01:57:06
Message-ID: 20200414015706.GF1492@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 13, 2020 at 04:22:26PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> 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
>> paths. Could we perhaps throw the error a bit later during the commit
>> processing?
>
> Any error post-commit is a semantic disaster.

Yes, I can immediately think of two problems in the very recent
history where this has bitten.

> I guess that an assertion wouldn't be so awful, if people would rather
> do it like that in debug builds.

WARNING is useful mainly for tests where the output is checked, like
the main regression test suite. Now that TAP scenarios get more and
more complex, +1 on the addition of an assertion for a hard failure.
I don't think either that's worth controlling with a developer GUC.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-04-14 02:22:42 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Previous Message Richard Guo 2020-04-14 01:50:39 Re: weird hash plan cost, starting with pg10