| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, wangpeng <215722532(at)qq(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dumpall --roles-only interact with other options |
| Date: | 2026-02-09 06:31:22 |
| Message-ID: | CACJufxFv1Tixecxk78hOO21BgT4mo36MZxH8HFfkP-jGMxm4NA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 6, 2026 at 5:36 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> Please see the attached tap test case. It works with the current
> master branch, and fails with the patch. Basically my expectation is
> that if we use dumpall --schema-only, we should be able to restore it
> without errors, except for one error for the already existing
> postgres/current user which it ignores.
>
> I also found one more issue/behavior change: --no-schema --clean now
> generates DROP statements (roles, tablespaces, databases), while
> previously it didn't.
hi.
It would be better to simply reject the CONFLICT ONLY option and keep the rest
of the logic same as the HEAD. That way, we avoid any surprising behavior.
IMHO.
Please check attached v5.
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-pg_dumpall-error-out-conflict-options.patch | text/x-patch | 11.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-09 06:44:35 | Re: Add expressions to pg_restore_extended_stats() |
| Previous Message | Hüseyin Demir | 2026-02-09 06:24:42 | Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists |