Re: [HACKERS] exit() behavior on Windows?
I wrote: > If it's just a quick kill, then there's a totally separate bug here for > Windows. What is likely to happen with the current coding is that a > failing child thread will queue its error message into the communication > pipe, and then exit(1), thereby killing the whole pg_dump process before > the master thread can receive and print the error. Ah, scratch that --- I hadn't noticed the badly-underdocumented #ifdef in exit_nicely(). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] exit() behavior on Windows?
Rather belatedly, I've started to look into a fix for pg_dump's problem with error reporting in parallel mode: http://www.postgresql.org/message-id/2458.1450894...@sss.pgh.pa.us One of the issues here is that pg_dump uses threads not subprocesses to do parallelism on Windows, which means that totally different reasoning is needed for that case. I'm looking in particular at the use of exit(). What I gather from Microsoft's documentation is that exit() will kill the whole process not just the calling thread --- can anyone confirm that that's correct? Are the other threads just killed asynchronously, or do they get a chance to shut down? If it's just a quick kill, then there's a totally separate bug here for Windows. What is likely to happen with the current coding is that a failing child thread will queue its error message into the communication pipe, and then exit(1), thereby killing the whole pg_dump process before the master thread can receive and print the error. The visible result would be about the same as what I described on Linux, ie failure exit with no error message reported. But the mechanism is different. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] exit() calls in libraries
On mån, 2011-12-05 at 15:04 -0300, Alvaro Herrera wrote:
> 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.
>
This is the patch that would get rid of all exit() calls in the
libraries.
diff --git i/src/interfaces/libpq/fe-print.c w/src/interfaces/libpq/fe-print.c
index 5fa3be0..a6c2959 100644
--- i/src/interfaces/libpq/fe-print.c
+++ w/src/interfaces/libpq/fe-print.c
@@ -112,17 +112,17 @@ PQprint(FILE *fout, const PGresult *res, const PQprintOpt *po)
if (!(fieldNames = (const char **) calloc(nFields, sizeof(char *
{
fprintf(stderr, libpq_gettext("out of memory\n"));
- exit(1);
+ abort();
}
if (!(fieldNotNum = (unsigned char *) calloc(nFields, 1)))
{
fprintf(stderr, libpq_gettext("out of memory\n"));
- exit(1);
+ abort();
}
if (!(fieldMax = (int *) calloc(nFields, sizeof(int
{
fprintf(stderr, libpq_gettext("out of memory\n"));
- exit(1);
+ abort();
}
for (numFieldName = 0;
po->fieldName && po->fieldName[numFieldName];
@@ -203,7 +203,7 @@ PQprint(FILE *fout, const PGresult *res, const PQprintOpt *po)
if (!(fields = (char **) calloc(nFields * (nTups + 1), sizeof(char *
{
fprintf(stderr, libpq_gettext("out of memory\n"));
-exit(1);
+abort();
}
}
else if (po->header && !po->html3)
@@ -391,7 +391,7 @@ do_field(const PQprintOpt *po, const PGresult *res,
if (!(fields[i * nFields + j] = (char *) malloc(plen + 1)))
{
fprintf(stderr, libpq_gettext("out of memory\n"));
-exit(1);
+abort();
}
strcpy(fields[i * nFields + j], pval);
}
@@ -462,7 +462,7 @@ do_header(FILE *fout, const PQprintOpt *po, const int nFields, int *fieldMax,
if (!border)
{
fprintf(stderr, libpq_gettext("out of memory\n"));
- exit(1);
+ abort();
}
p = border;
if (po->standard)
@@ -605,7 +605,7 @@ PQdisplayTuples(const PGresult *res,
if (!fLength)
{
fprintf(stderr, libpq_gettext("out of memory\n"));
- exit(1);
+ abort();
}
for (j = 0; j < nFields; j++)
@@ -704,7 +704,7 @@ PQprintTuples(const PGresult *res,
if (!tborder)
{
fprintf(stderr, libpq_gettext("out of memory\n"));
-exit(1);
+abort();
}
for (i = 0; i <= width; i++)
tborder[i] = '-';
diff --git i/src/interfaces/libpq/libpq-int.h w/src/interfaces/libpq/libpq-int.h
index 64dfcb2..a0d93e0 100644
--- i/src/interfaces/libpq/libpq-int.h
+++ w/src/interfaces/libpq/libpq-int.h
@@ -483,7 +483,7 @@ extern pgthreadlock_t pg_g_threadlock;
#define PGTHREAD_ERROR(msg) \
do { \
fprintf(stderr, "%s\n", msg); \
- exit(1); \
+ abort(); \
} while (0)
diff --git i/src/port/path.c w/src/port/path.c
index 9cb0b01..de345c2 100644
--- i/src/port/path.c
+++ w/src/port/path.c
@@ -445,7 +445,7 @@ get_progname(const char *argv0)
if (progname == NULL)
{
fprintf(stderr, "%s: out of memory\n", nodir_name);
- exit(1);/* This could exit the postmaster */
+ abort();/* This could exit the postmaster */
}
#if defined(__CYGWIN__) || defined(WIN32)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] exit() calls in libraries
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 The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] exit() calls in libraries
Debian's package policy and quality check tool lintian reports the following (among other things) on the postgresql-9.1 (and earlier) packages: X: libpq5: shlib-calls-exit usr/lib/libpq.so.5.4 X: libecpg6: shlib-calls-exit usr/lib/libecpg.so.6.3 which is explained as I: shlib-calls-exit N: N: The listed shared library calls the C library exit() or _exit() N: functions. N: N: In the case of an error, the library should instead return an N: appropriate error code to the calling program which can then determine N: how to handle the error, including performing any required clean-up. [snip] The report on libecpg is actually a false positive, because the exit() call comes from get_progname() in path.c, which is not called from functions in libecpg. 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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] exit
Marcos Fabrício Corso wrote: I would like to leave the list ... Not really a question worth posting several lists. If you don't know how to unsubscribe, try starting with the form linked from here. http://www.postgresql.org/community/lists/ -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] exit
I would like to leave the list ... -- Acelerador POP Acelere a sua conexão discada em até 19 x. Use o Acelerador POP. É grátis, pegue já o seu. http://www.pop.com.br/acelerador
Re: [HACKERS] exit status 512
Peter Galantha <[EMAIL PROTECTED]> writes: > Hi hackers, > there was a hardware failure 'couse we had to turn off the computer manually. > After the hardware change, the database reports exit status 512. > Can anybody help me what 'Startup proc 850 exited with status 512' mean? You're showing us the wrong error message, ie, the postmaster's complaint that the startup process failed, not the startup process's report about why. What does it say before that? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] exit status 512
Hi hackers, there was a hardware failure 'couse we had to turn off the computer manually. After the hardware change, the database reports exit status 512. Can anybody help me what 'Startup proc 850 exited with status 512' mean? how can I solve this problem? Peter Galantha argosz at tensa.net ---(end of broadcast)--- TIP 8: explain analyze is your friend
