Re: pg_dump why no indicator of completion

Scott,

Generally I run pg_dump nohup in the background with all outputs captured
to a file. Finding the exit message is simply a matter of navigating to
the bottom of the output file and checking.
Excepting for pg_dump, I don't generally have to worry about exit values as
most command line programs are either short-lived and obvious, like ls, or
emit their own text exit status.
In my experience checking exit status codes are what you do when writing
programs to determine the status of a subroutine or function that you are
calling. Stand alone programs that are expected to take any appreciable
amount of time to run generally provide an status output, precisely for
this reason.

I hope that the devs reconsider and add a status output message. If
checking the exit status is the only way to determine if the pg_dump
process completed successfully, then I am going to be forced to create a
wrapper to capture and emit the status around the pg_dump executable. If I
need to do that, so will every other user who needs to know the exit status
and runs pg_dump in a typical linux workflow. Seems like a terrible waste
having untold numbers of users having to constantly reinvent the wheel.

rik.

On Mon, May 1, 2023 at 9:07 AM Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
wrote:

> > On May 1, 2023, at 7:01 AM, richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
> wrote:
> >
> > Which, running more than one command from the shell prompt in a single
> logon session, or not emitting an exit message?
>
> Running multiple long-lived processes in a shell prompt, whose exit values
> you care about, running in the background, along with "a myriad of other
> commands", presumably short-lived, in the interim, then looking through
> "the flotsam and jetsam" for a success message. Sounds like a total mess.
> Put your important long-lived processesin their own sessions. Or, if you
> must interleave them, wrap the call to pg_dump in a simple conditional.