On Tue, Sep 20, 2016 at 9:25 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers