On Tue, Apr 3, 2012 at 11:04 AM, Robert Haas <[email protected]> wrote:
> OK, but it seems like a pretty fragile assumption that none of the
> workers will ever manage to emit any other error messages. We don't
> rely on this kind of assumption in the backend, which is a lot
> better-structured and less spaghetti-like than the pg_dump code.
Yeah, but even if they don't use exit_horribly(), the user would still
see the output, stdout/stderr aren't closed and everyone can still
write to it.
As a test, I printed out some messages upon seeing a specific dump id
in a worker:
if (strcmp(command, "DUMP 3540") == 0)
{
write_msg(NULL, "Info 1\n");
printf("Info 2\n");
exit_horribly(modulename, "that's why\n");
}
$ ./pg_dump -j 7 ...
pg_dump: Info 1
Info 2
pg_dump: [parallel archiver] that's why
if (strcmp(command, "DUMP 3540") == 0)
{
write_msg(NULL, "Info 1\n");
printf("Info 2\n");
fprintf(stderr, "exiting on my own\n");
exit(1);
}
$ ./pg_dump -j 7 ...
pg_dump: Info 1
Info 2
exiting on my own
pg_dump: [parallel archiver] A worker process died unexpectedly
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
