Re: patch for parallel pg_dump - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: patch for parallel pg_dump
Date
Msg-id CACw0+12PKuT+hc8rnmtYOT7eiD0Q0Az_cExK3T__oj_WdHFWFg@mail.gmail.com
Whole thread Raw
In response to Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Apr 3, 2012 at 11:04 AM, Robert Haas <robertmhaas@gmail.com> 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


pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: bugfix for cursor arguments in named notation
Next
From: Boszormenyi Zoltan
Date:
Subject: [PATCH] lock_timeout and common SIGALRM framework