Re: Fix Error Message for allocate_recordbuf() Failure

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Fix Error Message for allocate_recordbuf() Failure
Дата
Msg-id CA+TgmoaHD0caVK2FGiW_7MuhMhw6sg2gRcvpz8HgyZ266sTSJA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix Error Message for allocate_recordbuf() Failure  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Tue, Sep 20, 2016 at 9:25 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> For what it's worth, I think it's fine.  Good error messages are a useful thing.
>>
>> More generally, I think the whole patch looks good and should be committed.
>
> Hm. I'd think that it is still more portable to just issue a WARNING
> message in palloc_extended() when MCXT_ALLOC_NO_OOM then. Other code
> paths could benefit from that as well, and the patch proposed does
> nothing for the other places calling it. I am fine to write a patch
> for this purpose if you agree on that.

No, I strongly disagree with that.  I think when you pass
MCXT_ALLOC_NO_OOM, you're saying that you are prepared to deal with a
NULL return value.  It becomes your job to decide whether to emit any
log message and which one to emit.  If palloc_extended() insists on
emitting a warning regardless, the caller can't now emit a more
specific message without creating redundant log chatter.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: pageinspect: Hash index support
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Logical Replication WIP