Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL 9.4.x

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: Bill Parker <wp02855(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL 9.4.x
Date: 2015-06-15 07:35:47
Message-ID: CAB7nPqS2-48njPJ-_PHcfQA1569f4z73rFDpNeBkF_gwB8fSKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Jun 12, 2015 at 10:06 PM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
> On Fri, Jun 12, 2015 at 03:53:43PM +0900, Michael Paquier wrote:
>> (Adding Michael Meskes in CC:)
>
> Thanks.
>
>> Nice catch. Regarding your patch, it seems to me that this is not
>> enough. I think that we should return NULL with ECPGget_sqlca in case
>> of an OOM instead of logging a message with ecpg_log and let each code
>> path decide what to do when sqlca is NULL. Some code paths can
>> directly use ecpg_raise with ECPG_OUT_OF_MEMORY. Other code paths,
>> like the ones in error.c will need to show up with appropriate error
>> messages.
>
> Agreed on all accounts.

So, here is a patch implementing those ideas. In code paths where a
line number is available ecpg_raise() is called to report the error.
In other paths ecpg_log() is used to log an "out of memory" message.
Now, the routines of error.c, like ecpg_raise() can fail as well their
malloc() call, hence it seems adapted to me to fallback to ecpg_log()
and report the error to the user.
Thoughts?
--
Michael

Attachment Content-Type Size
20150615_ecpg_fix_malloc.patch binary/octet-stream 7.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message digoal 2015-06-15 09:05:23 BUG #13443: master will remove dead rows when hot standby(use slot) disconnect
Previous Message Alvaro Herrera 2015-06-15 04:50:56 Re: BUG #13440: unaccent does not remove all diacritics