Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL 9.4.x
| От | Michael Paquier |
|---|---|
| Тема | Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL 9.4.x |
| Дата | |
| Msg-id | CAB7nPqS2-48njPJ-_PHcfQA1569f4z73rFDpNeBkF_gwB8fSKw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL 9.4.x (Michael Meskes <meskes@postgresql.org>) |
| Ответы |
Re: Lack of Sanity Checking in file 'misc.c' for PostgreSQL
9.4.x
|
| Список | pgsql-bugs |
On Fri, Jun 12, 2015 at 10:06 PM, Michael Meskes <meskes@postgresql.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
Вложения
В списке pgsql-bugs по дате отправления: