Re: relcache leak warnings vs. errors
От | Tom Lane |
---|---|
Тема | Re: relcache leak warnings vs. errors |
Дата | |
Msg-id | 17297.1586809346@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: relcache leak warnings vs. errors (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: relcache leak warnings vs. errors
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> 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. >> Although I suppose that it's not really worse than other assertion >> failures. > 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. I guess that an assertion wouldn't be so awful, if people would rather do it like that in debug builds. regards, tom lane
В списке pgsql-hackers по дате отправления: