Thread: Feature suggestions for backup and replication
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 and this would help immensely to see bottlenecks, time distribution and get an overall feel for which steps take how long.
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
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 and this would help immensely to see bottlenecks, time distribution and get an overall feel for which steps take how long.
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
On 11/7/22 16:03, da avory wrote:
Are you using "--jobs=X --format=directory", or old school plain text dumps?
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.
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.
Angular momentum makes the world go 'round.