From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Feature suggestions for backup and replication |
Date: | 2022-11-08 13:02:09 |
Message-ID: | 90638847-49ea-d245-2035-dc53a2a47a61@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/7/22 16:03, da avory wrote:
> Hi all,
>
> not sure whether this is the right list to ask. I do have two (small!?)
> feature suggestions, both regarding backup and replication, which might
> appeal to a wider audience.
>
> 1) it would be very great to have the option to add a timestamp to all
> lines of output of pg_dump and pg_restore. We regularly do dump/restores
> that take multiple days
Are you using "--jobs=X --format=directory", or old school plain text dumps?
> and this would help immensely to see bottlenecks, time distribution and
> get an overall feel for which steps take how long.
While timestamps would definitely be useful, the --verbose option with
stdout *and* stderr redirected to a file plus some manual effort will answer
your questions.
>
> 2) It would be equally great to be able to retrieve the actual value of
> recovery_min_apply_delay config parameter that is configured on a
> streaming client as a value on the primary (as a field in
> pg_stat_replication). Ideally in a consistent form, i.e. converted to
> seconds or interval. We currently have our ops team monitoring our
> streaming clients in various monitoring views and while we can of course
> see pending transfer and replay volume there is no way to see the intended
> apply_delay without storing it somewhere on the primary (where it will get
> inevitably out of sync with the used value).
>
> Many thanks
>
> Dean
--
Angular momentum makes the world go 'round.
From | Date | Subject | |
---|---|---|---|
Next Message | Albrecht Dreß | 2022-11-08 13:16:03 | Q: pg_hba.conf separate database names file format |
Previous Message | Karsten Hilbert | 2022-11-08 11:33:39 | Aw: Information to CVE-2022-42889 |