public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v6 02/10] doc: pg_stat_progress_basebackup 4+ messages / 3 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; 4+ 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] 4+ messages in thread
* Re: pg_combinebackup --clone doesn't work @ 2024-06-25 13:21 Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Peter Eisentraut @ 2024-06-25 13:21 UTC (permalink / raw) To: Tomas Vondra <[email protected]>; pgsql-hackers On 21.06.24 18:10, Tomas Vondra wrote: > On 6/21/24 00:07, Tomas Vondra wrote: >> Here's a fix adding the missing headers to pg_combinebackup, and fixing >> some compile-time issues in the ifdef-ed block. >> >> I've done some basic manual testing today - I plan to test this a bit >> more tomorrow, and I'll also look at integrating this into the existing >> tests. >> > > Here's a bit more complete / cleaned patch, adding the testing changes > in separate parts. > > 0001 adds the missing headers / fixes the now-accessible code a bit > > 0002 adds the --copy option for consistency with pg_upgrade This looks good. > 0003 adds the PG_TEST_PG_COMBINEBACKUP_MODE, so that we can override the > copy method for tests I had imagined that we combine PG_TEST_PG_UPGRADE_MODE and this new one into one setting. But maybe that's something to consider with less time pressure for PG18. > I believe 0001-0003 are likely non-controversial, although if someone > could take a look at the Perl in 0003 that'd be nice. Also, 0002 seems > nice not only because of consistency with pg_upgrade, but it also makes > 0003 easier as we don't need to special-case the default mode etc. Right, that was one of the reasons. > 0004 tweaks two of the Cirrus CI tasks to use --clone/--copy-file-range > I'm not sure about 0004 - I initially did this mostly to check we have > the right headers on other platforms, but not sure we want to actually > do this. Or maybe we want to test a different combination (e.g. also > test the --clone on Linux)? It's tricky to find the right balance here. We had to figure this out for pg_upgrade as well. I think your solution is good, and we should also add test coverage for pg_upgrade --copy-file-range in the same place, I think. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_combinebackup --clone doesn't work @ 2024-06-30 18:58 Tomas Vondra <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Tomas Vondra @ 2024-06-30 18:58 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; pgsql-hackers Hi, I've pushed the first three patches, fixing the headers, adding the --copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable. I haven't pushed the CI changes, I'm not sure if there's a clear consensus on which combination to test. It's something we can tweak later, I think. FWIW I've added the patch to the 2024-07 commitfest, but mostly to get some CI runs (runs on private fork fail with some macos issues unrelated to the patch). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Attachments: [text/x-patch] 0001-Add-PG_TEST_PG_COMBINEBACKUP_MODE-to-CI-tasks.patch (1.2K, ../../[email protected]/2-0001-Add-PG_TEST_PG_COMBINEBACKUP_MODE-to-CI-tasks.patch) download | inline diff: From c92cc862026d1d2e48dd97e05f497873fb852588 Mon Sep 17 00:00:00 2001 From: Tomas Vondra <[email protected]> Date: Sun, 30 Jun 2024 19:03:02 +0200 Subject: [PATCH 4/4] Add PG_TEST_PG_COMBINEBACKUP_MODE to CI tasks This changes pg_combinebackup mode for two of the Cirrus CI tasks, to exercise the alternative copy methods in pg_combinebackup tests. We test --clone on macOS and --copy-file-range on one of the Linux tasks. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org --- .cirrus.tasks.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml index 33646faeadf..4e029103c7e 100644 --- a/.cirrus.tasks.yml +++ b/.cirrus.tasks.yml @@ -318,6 +318,7 @@ task: env: SANITIZER_FLAGS: -fsanitize=address + PG_TEST_PG_COMBINEBACKUP_MODE: --copy-file-range # Normally, the "relation segment" code basically has no coverage in our # tests, because we (quite reasonably) don't generate tables large @@ -432,6 +433,7 @@ task: CXXFLAGS: -Og -ggdb PG_TEST_PG_UPGRADE_MODE: --clone + PG_TEST_PG_COMBINEBACKUP_MODE: --clone <<: *macos_task_template -- 2.45.2 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_combinebackup --clone doesn't work @ 2024-08-23 12:00 Peter Eisentraut <[email protected]> parent: Tomas Vondra <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Peter Eisentraut @ 2024-08-23 12:00 UTC (permalink / raw) To: Tomas Vondra <[email protected]>; pgsql-hackers On 30.06.24 20:58, Tomas Vondra wrote: > I've pushed the first three patches, fixing the headers, adding the > --copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable. > > I haven't pushed the CI changes, I'm not sure if there's a clear > consensus on which combination to test. It's something we can tweak > later, I think. > > FWIW I've added the patch to the 2024-07 commitfest, but mostly to get > some CI runs (runs on private fork fail with some macos issues unrelated > to the patch). This last patch is still pending in the commitfest. Personally, I think it's good to commit as is. ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-08-23 12:00 UTC | newest] Thread overview: 4+ 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]> 2024-06-25 13:21 Re: pg_combinebackup --clone doesn't work Peter Eisentraut <[email protected]> 2024-06-30 18:58 ` Re: pg_combinebackup --clone doesn't work Tomas Vondra <[email protected]> 2024-08-23 12:00 ` Re: pg_combinebackup --clone doesn't work Peter Eisentraut <[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