| От | Michael Paquier |
|---|---|
| Тема | Re: relcache leak warnings vs. errors |
| Дата | |
| Msg-id | 20200414015706.GF1492@paquier.xyz обсуждение |
| Ответ на | Re: relcache leak warnings vs. errors (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Mon, Apr 13, 2020 at 04:22:26PM -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера