| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew <pgsqlhackers(at)andrewrepp(dot)com> |
| Subject: | Re: pg_dump versus hash partitioning |
| Date: | 2023-02-27 17:50:15 |
| Message-ID: | 389892.1677520215@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Feb 27, 2023 at 11:20 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, that's a user error not pg_dump's fault. Particularly so for hash
>> partitioning, where there is no defensible reason to make the partitions
>> semantically different.
> I am still of the opinion that you're going down a dangerous path of
> redefining pg_dump's mission from "dump and restore the database, as
> it actually exists" to "dump and restore the database, unless the user
> did something that I think is silly".
Let's not attack straw men, shall we? I'm defining pg_dump's mission
as "dump and restore the database successfully". Failure to restore
does not help anyone, especially if they are in a disaster recovery
situation where it's not possible to re-take the dump. It's not like
there's no precedent for having pg_dump tweak things to ensure a
successful restore.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2023-02-27 17:55:01 | Re: pg_dump versus hash partitioning |
| Previous Message | Tom Lane | 2023-02-27 17:42:00 | Re: tests against running server occasionally fail, postgres_fdw & tenk1 |