On Wed, Feb 1, 2023 at 6:14 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > You waved your arms about inventing some new hashing infrastructure, > but it was phrased in such a way that it wasn't clear to me if that > was actually a serious proposal or not. But if it is: how will you > get around the fact that any change to hashing behavior will break > pg_upgrade of existing hash-partitioned tables? New infrastructure > avails nothing if it has to be bug-compatible with the old. So I'm > not sure how restricting the fix to master helps us.
I think what I'd propose to do is invent a new method of hashing enums that can be used for hash partitioning on enum columns going forward, and make it the default for hash partitioning going forward. The existing method can continue to be used for hash indexes, to avoid breaking on disk compatibility. Now, for the back branches, if you wanted to force --load-via-partition-root specifically for the case of hash partitioning on an enum column, I think that would be fine. It's a hack, but there's no way out in the back branches that is not a hack. What I don't like is the idea of enabling --load-via-partition-root in the back branches more broadly, e.g. in all cases whatsoever, or in all cases involving hash partitioning. If we really want to, we can make --load-via-partition-root the new default categorically in master, and make the pg_dump option --no-load-via-partition-root. I'm not convinced that's a good idea, but maybe it is, and you know, major releases change behavior sometimes, that's how life goes. Minor releases, though, should minimize behavior changes, IMHO. It's not at all nice to apply a critical security update and find that pg_dump works differently to fix a problem you weren't having. -- Robert Haas EDB: http://www.enterprisedb.com