Re: pg_dump verbose start and stop times? - Mailing list pgsql-admin

From Ron Johnson
Subject Re: pg_dump verbose start and stop times?
Date
Msg-id CANzqJaD6z-mavVkiYM4SPmKuPTva6JSE4S0zgqsMcVVJYxDNYQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump verbose start and stop times?  (hubert depesz lubaczewski <depesz@depesz.com>)
List pgsql-admin
On Fri, May 30, 2025 at 9:48 AM hubert depesz lubaczewski <depesz@depesz.com> wrote:
On Fri, May 30, 2025 at 08:54:24AM -0400, Ron Johnson wrote:
> And yet it's not possible to show how long it takes to copy each object .
> This, at least, does the math to show the grand elapsed time, and puts an
> easily greppable string in the cron job's stdout+stderr log file:
>
> time_it()
> {
>     local ActionLabel=$1
>     shift
>     date +"%n%F %T TIMEIT $ActionLabel started.%n"
>     START_SECS=$(date +"%s")
>     $@
>     local RC=$? ; echo "TIMEIT Return Code = $RC"
>     FINISH_SECS=$(date +"%s")
>     ET=$(echo "scale=2;(${FINISH_SECS} - ${START_SECS})/60" | bc)
>     date +"%n%F %T TIMEIT $ActionLabel finished. Elapsed time: ${ET}
> minutes."
>     return $RC
> }
>
> time_it DUMP_$DB pg_dump -j ${Threads} -Z${ZLvl} -v -C -Fd --file=$DB $DB
> 2> ${DB}_pgdump.log

You do know that you could have just done:

time pg_dump …

without the time_it function?

Without the easily greppable string that shows what action it performed.  That's why I wrote the function: to have a standard, constant string to grep.
 
And if you'd want to write your own function, assuming you're running
not-so-ancient bash, you could have just used $EPOCHREALTIME and not the
date +… ?

RHEL 8 is apparently ancient.

When all my RHEL 7 and 8 servers are retired, I might change it to use $EPOCHREALTIME.  Or maybe not;  ancient, forgotten servers lurk everywhere, and this probably works on RHEL 6.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

pgsql-admin by date:

Previous
From: Joe Tailleur
Date:
Subject: Re: Seeking Suggestions for Best Practices: Archiving and Migrating Historical Data in PostgreSQL
Next
From: Ron Johnson
Date:
Subject: Re: Seeking Suggestions for Best Practices: Archiving and Migrating Historical Data in PostgreSQL