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
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
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
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
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
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
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
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
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
