bug: pg_dumpall with --data-only and --clean options is giving an error after some dump

Hello,

On Sun, Mar 15, 2026 at 12:49 AM Mahendra Singh Thalor <mahi6run@gmail.com>
wrote:

Hi all,

I was doing some tests with pg_dump, pg_dumpall and pg_restore tools. With
"pg_dumpall --data-only --clean", we are reporting an error after dumping
some data.

Please see the example below.

./pg_dumpall --data-only --clean

--
-- PostgreSQL database cluster dump
--

\restrict ZQDDv56JBW8CVfkLsRDeyRpBvDGYUeqhZbJkDccKbXG8q6PI4RB69Dd8KaqcWMY

SET default_transaction_read_only = off;

SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;

\unrestrict
ZQDDv56JBW8CVfkLsRDeyRpBvDGYUeqhZbJkDccKbXG8q6PI4RB69Dd8KaqcWMY

--
-- Databases
--

--
-- Database "template1" dump
--

pg_dump: error: options -c/--clean and -a/--data-only cannot be used
together
pg_dumpall: error: pg_dump failed on database "template1", exiting

Error is coming from pg_dump but it should come from pg_dumpall without
any dump.

Here, I am attaching a patch to fix this problem. Please review this.

+1 for the fix , as it immediately throws an error in pg_dumpall itself,
instead of going through all the way until pg_dump and then finding
out it's not a correct combination of options.

I have reviewed,tested the patch , except these it LGTM.
1) maybe match the pg_dumpall comment with the pg_dump comment.
2) please fix the indentation using pgindent

diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index 47a062d0160..b47e683e1d4 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -455,9 +455,9 @@ main(int argc, char *argv[])
                                                schema_only,
"-s/--schema-only",
                                                tablespaces_only,
"-t/--tablespaces-only");

-       /* --clean and --data-only are incompatible */
+       /* --clean is incompatible with --data-only */
        check_mut_excl_opts(output_clean, "-c/--clean",
-                       data_only, "-a/--data-only");
+                                               data_only,
"-a/--data-only");

if (if_exists && !output_clean)
pg_fatal("option %s requires option %s",

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

On 2026-03-14 Sa 3:18 PM, Mahendra Singh Thalor wrote:

Hi all,

I was doing some tests with pg_dump, pg_dumpall and pg_restore tools.
With "pg_dumpall --data-only --clean", we are reporting an error after
dumping some data.

Hmm, this looks like behaviour that goes a long way back. Should we
backpatch this fix?

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2026-Mar-15, Andrew Dunstan wrote:

On 2026-03-14 Sa 3:18 PM, Mahendra Singh Thalor wrote:

I was doing some tests with pg_dump, pg_dumpall and pg_restore tools.
With "pg_dumpall --data-only --clean", we are reporting an error after
dumping some data.

Hmm, this looks like behaviour that goes a long way back. Should we
backpatch this fix?

IMO it would make sense to do so.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

Thanks Andrew, Álvaro and Srinath for the review and feedback.

1) maybe match the pg_dumpall comment with the pg_dump comment.

I took this comment from pg_restore so i am keeping this same as pg_restore.

2) please fix the indentation using pgindent
--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

Fixed.

On Sun, 15 Mar 2026 at 17:41, Álvaro Herrera <alvherre@kurilemu.de> wrote:

Hi,

On 2026-Mar-15, Andrew Dunstan wrote:

On 2026-03-14 Sa 3:18 PM, Mahendra Singh Thalor wrote:

I was doing some tests with pg_dump, pg_dumpall and pg_restore tools.
With "pg_dumpall --data-only --clean", we are reporting an error after
dumping some data.

Hmm, this looks like behaviour that goes a long way back. Should we
backpatch this fix?

IMO it would make sense to do so.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

As per suggestions, I made patches till PG14.

Here, I am attaching updated patches.

--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:

Hmm, this looks like behaviour that goes a long way back. Should we
backpatch this fix?

I wouldn't bother. At the end of the day you get the same failure
report anyway.

regards, tom lane

On Sun, Mar 15, 2026 at 12:20:41PM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Hmm, this looks like behaviour that goes a long way back. Should we
backpatch this fix?

I wouldn't bother. At the end of the day you get the same failure
report anyway.

Agreed, I don't think back-patching is worth the (probably low) risk. The
latest patch for v19 looks good to me. I recently committed some stuff in
this area, so I can take care of committing this one, too.

--
nathan

On Mon, Mar 16, 2026 at 09:52:21AM -0500, Nathan Bossart wrote:

Agreed, I don't think back-patching is worth the (probably low) risk. The
latest patch for v19 looks good to me. I recently committed some stuff in
this area, so I can take care of committing this one, too.

Committed.

--
nathan