Re: exit() calls in libraries

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: exit() calls in libraries
Date: 2011-12-05 18:04:15
Message-ID: 1323106543-sup-1163@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Peter Eisentraut's message of lun dic 05 14:27:41 -0300 2011:

> The cases in libpq are
>
> * various places in fe-print.c calling exit(1) when malloc fails,
> presumably having run out of memory, and
> * in libpq-int.h the macro PGTHREAD_ERROR, which is called in
> several places in fe-connect.c and fe-secure.c.
>
> Are these appropriate behaviors? The fe-print.c stuff probably isn't
> used much anymore. But the threading stuff is, and it encroaches on the
> exit status space of the libpq-using program. And does it even make
> sense to call exit() if the thread locking is busted? Maybe abort()
> would work better?

Having had to battle some exit() calls in the PHP interpreter back when
I was working in PL/php, I agree that they shouldn't be there -- abort()
seems more appropriate if the system is truly busted. As for the
fr-print.c code, I'm not really sure why don't we just remove it.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-12-05 18:11:54 Re: pgsql: plpython: Add SPI cursor support
Previous Message Jan Urbański 2011-12-05 17:59:58 Re: plpython SPI cursors