pg_dumpall dumps global objects with --statistics-only or --no-schema

Started by Fujii Masao7 months ago3 messages
#1Fujii Masao
masao.fujii@oss.nttdata.com
1 attachment(s)

Hi,

While testing pg_dumpall in v18, I noticed that it still dumps global objects
such as roles and tablespaces even when --statistics-only or --no-schema is
specified. This seems unexpected.

Since pg_dumpall treats global objects as schema-level content, it currently
includes them with --schema-only but skips them with --data-only. By that logic,
it should also skip them when either --statistics-only or --no-schema is used.
Thought?

Attached is a patch to fix this behavior.

Originally, I planned to work on this after we settled the ongoing discussion
about pg_dump options in [1]/messages/by-id/7cc52488-f876-4ad3-affd-6e4b0ef0cb09@eisentraut.org, but since that may take some time, I wanted to
bring this up now so I don't forget the issue.

Regards,

[1]: /messages/by-id/7cc52488-f876-4ad3-affd-6e4b0ef0cb09@eisentraut.org

--
Fujii Masao
NTT DATA Japan Corporation

Attachments:

v1-0001-pg_dumpall-Skip-global-objects-with-statistics-on.patchtext/plain; charset=UTF-8; name=v1-0001-pg_dumpall-Skip-global-objects-with-statistics-on.patchDownload
From a3cd7c76f456144c62e3652cf3edd77d2d8d3816 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Tue, 24 Jun 2025 23:56:28 +0900
Subject: [PATCH v1] pg_dumpall: Skip global objects with --statistics-only or
 --no-schema.

Previously, pg_dumpall would still dump global objects such as roles
and tablespaces even when --statistics-only or --no-schema was specified.
Since these global objects are treated as schema-level data, they should
be skipped in these cases.

This commit fixes the issue by ensuring that global objects are not
dumped when either --statistics-only or --no-schema is used.
---
 src/bin/pg_dump/pg_dumpall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index 3cbcad65c5f..100317b1aa9 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -632,7 +632,7 @@ main(int argc, char *argv[])
 		fprintf(OPF, "SET escape_string_warning = off;\n");
 	fprintf(OPF, "\n");
 
-	if (!data_only)
+	if (!data_only && !statistics_only && !no_schema)
 	{
 		/*
 		 * If asked to --clean, do that first.  We can avoid detailed
-- 
2.49.0

#2Corey Huinker
corey.huinker@gmail.com
In reply to: Fujii Masao (#1)
Re: pg_dumpall dumps global objects with --statistics-only or --no-schema

Since pg_dumpall treats global objects as schema-level content, it
currently
includes them with --schema-only but skips them with --data-only. By that
logic,
it should also skip them when either --statistics-only or --no-schema is
used.
Thought?

+1, pending resolution of the defaults issue.

At first glance, this looks like a good candidate for the the same refactor
that we did to pg_dump in 96a81c1be929, where we abandoned using the
schema_only and data_only flags to determine what should be dumped in favor
of dumpSchema, dumpData, and eventually dumpStatistics. This made for a
cleaner interface because each test was described in terms of what was
wanted, not in terms of the opposite being not the case, and all of the
double/triple-negative boolean backflips were concentrated right after the
options conflict resolutions.

However, all prospective do_this_thing branches are used exactly once, so
there is no code savings to be had and no clarity to be gained, so this
patch is fine as is.

#3Jeff Davis
pgsql@j-davis.com
In reply to: Corey Huinker (#2)
Re: pg_dumpall dumps global objects with --statistics-only or --no-schema

On Mon, 2025-06-30 at 16:44 -0400, Corey Huinker wrote:

Since pg_dumpall treats global objects as schema-level content, it
currently
includes them with --schema-only but skips them with --data-only.
By that logic,
it should also skip them when either --statistics-only or --no-
schema is used.

Thank you.

+1, pending resolution of the defaults issue.

I went ahead and committed this as it clearly needs to be fixed. We can
continue the options discussion.

Regards,
Jeff Davis