public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v6 02/10] doc: pg_stat_progress_basebackup 2+ messages / 2 participants [nested] [flat]
* [PATCH v6 02/10] doc: pg_stat_progress_basebackup @ 2020-03-30 02:22 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-03-30 02:22 UTC (permalink / raw) commit e65497df8f85ab9b9084c928ff69f384ea729b24 Author: Fujii Masao <[email protected]> --- doc/src/sgml/monitoring.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 304c49f07b..ea8780327f 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -6069,8 +6069,8 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, <entry><literal>waiting for checkpoint to finish</literal></entry> <entry> The WAL sender process is currently performing - <function>pg_start_backup</function> to set up for - taking a base backup, and waiting for backup start + <function>pg_start_backup</function> to prepare to + take a base backup, and waiting for the start-of-backup checkpoint to finish. </entry> </row> -- 2.17.0 --C+ts3FVlLX8+P6JN Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v6-0003-Fix-docs-time-of-the.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Time delayed LR (WAS Re: logical replication restrictions) @ 2023-01-20 06:13 Takamichi Osumi (Fujitsu) <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Takamichi Osumi (Fujitsu) @ 2023-01-20 06:13 UTC (permalink / raw) To: 'Kyotaro Horiguchi' <[email protected]>; [email protected] <[email protected]>; +Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; pgsql-hackers; [email protected] <[email protected]> Hi, Horiguchi-san and Amit-san On Wednesday, November 9, 2022 3:41 PM Kyotaro Horiguchi <[email protected]> wrote: > Using interval is not standard as this kind of parameters but it seems > convenient. On the other hand, it's not great that the unit month introduces > some subtle ambiguity. This patch translates a month to 30 days but I'm not > sure it's the right thing to do. Perhaps we shouldn't allow the units upper than > days. In the past discussion, we talked about the merits to utilize the interval type. On the other hand, now we are facing some incompatibility issues of parsing between this time-delayed feature and physical replication's recovery_min_apply_delay. For instance, the interval type can accept '600 m s h', '1d 10min' and '1m', but the recovery_min_apply_delay makes the server failed to start by all of those. Therefore, this would confuse users and I'm going to make the feature's input compatible with recovery_min_apply_delay in the next version. Best Regards, Takamichi Osumi ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-01-20 06:13 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-03-30 02:22 [PATCH v6 02/10] doc: pg_stat_progress_basebackup Justin Pryzby <[email protected]> 2023-01-20 06:13 Re: Time delayed LR (WAS Re: logical replication restrictions) Takamichi Osumi (Fujitsu) <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox