Dependencies for partitioned indexes are still a mess

2020-07-15 Thread Tom Lane
I've been experimenting with trying to dump-and-restore the regression database, which is a test case that for some reason we don't cover in the buildfarm (pg_upgrade is not the same thing). It seems like the dependency choices we've made for partitioned indexes are a complete failure for this purp

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Alvaro Herrera
On 2020-Jul-15, Tom Lane wrote: > Issue #1: "--clean" does not work > > 1. createdb r2 > 2. pg_restore -d r2 regression.dump > 3. pg_restore --clean -d r2 regression.dump > > pg_restore: while PROCESSING TOC: > pg_restore: from TOC entry 6606; 1259 35458 INDEX idxpart32_a_idx postgres > pg_resto

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Andres Freund
Hi, On 2020-07-15 15:52:03 -0400, Tom Lane wrote: > I've been experimenting with trying to dump-and-restore the > regression database, which is a test case that for some reason > we don't cover in the buildfarm (pg_upgrade is not the same thing). Yea, we really should have that. IIRC I was trying

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Tom Lane
Andres Freund writes: > I've attached the diff between first.sql and second.sql. Here's the > highlights: As I recall, the differences in b_star etc are expected, because pg_dump reorders that table's columns to match its inheritance parent, which they don't to start with because of ALTER TABLE o

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Andres Freund
Hi, On 2020-08-12 18:29:16 -0400, Tom Lane wrote: > Andres Freund writes: > > I've attached the diff between first.sql and second.sql. Here's the > > highlights: > > As I recall, the differences in b_star etc are expected, because > pg_dump reorders that table's columns to match its inheritance

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Alvaro Herrera
On 2020-Jul-15, Tom Lane wrote: > Issue #2: parallel restore does not work > > 1. dropdb r2; createdb r2 > 2. pg_restore -j8 -d r2 regression.dump > > This is fairly timing-dependent, but some attempts fail with messages > like > > pg_restore: while PROCESSING TOC: > pg_restore: from TOC entry

Re: Dependencies for partitioned indexes are still a mess

2020-08-12 Thread Tom Lane
Andres Freund writes: > Given that pg_dump already re-orders the columns for DDL, could we make > it apply that re-ordering not just during the CREATE TABLE, but also > when dumping the table contents? Hm, possibly. I think when this was last looked at, we didn't have any way to get COPY to outp

Re: Dependencies for partitioned indexes are still a mess

2020-08-14 Thread Alvaro Herrera
On 2020-Aug-12, Alvaro Herrera wrote: > Hmm, we do make the FK constraint depend on the ATTACH for the direct > children; what I think we're lacking is dependencies on descendants > twice-removed (?) or higher. This mock patch seems to fix this problem > by adding dependencies recursively on all

Re: Dependencies for partitioned indexes are still a mess

2020-08-14 Thread Alvaro Herrera
On 2020-Aug-14, Alvaro Herrera wrote: > On 2020-Aug-12, Alvaro Herrera wrote: > > > Hmm, we do make the FK constraint depend on the ATTACH for the direct > > children; what I think we're lacking is dependencies on descendants > > twice-removed (?) or higher. This mock patch seems to fix this pro

Re: Dependencies for partitioned indexes are still a mess

2020-09-01 Thread Alvaro Herrera
On 2020-Aug-12, Alvaro Herrera wrote: > On 2020-Jul-15, Tom Lane wrote: > > (There seem to be some other problems as well, but most of the 54 complaints > > are related to partitioned indexes/constraints.) > > In my run of it there's a good dozen remaining problems, all alike: we > do DROP TYPE