Re: pg_restore --clean failing due to dependancies

From: "Arnaud L(dot)" <arnaud(dot)listes(at)codata(dot)eu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgreSQL(dot)org
Subject: Re: pg_restore --clean failing due to dependancies
Date: 2016-11-17 08:06:44
Message-ID: 82a55c10-0044-121e-5e23-5bf6a6cecfa4@codata.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Le 16/11/2016 à 20:05, Tom Lane a écrit :
> Arnaud Lesauvage <arnaud(dot)lesauvage(at)codata(dot)eu> writes:
>> [ dump from problematic database ]
>
> OK, thanks for the test case. The problem here is that pg_dump is setting
> up a circular dependency that it doesn't know how to break correctly.
> You've got a couple of views that are implicitly dependent on the primary
> keys of their underlying tables, because they use a GROUP BY the primary
> key without also grouping by other columns they use post-grouping. That
> means that pg_dump has to dump the view definition after the creation of
> the primary key, but it also needs to put the view out sooner than that
> for other reasons. It manages to deal with that okay in the default mode,
> but when you have --clean in there, it ends up generating an illegal DROP
> RULE command.

All right, at least I'm glad that I did not miss something obvious.

> This is something we ought to fix, but it's not exactly trivial to do.
> In the meantime I'd suggest changing the view definitions to not assume
> that the underlying tables have primary keys. It looks like in
> view_temp_export_geo_recherche_extra_sites_projets you need to add
> c.official_language_id to the GROUP BY, and similarly in
> view_temp_export_geo_recherche_offtrad_sites.

Thanks for the tip ! I'll try this ASAP.
I never "GROUP BY" primary keys only, so I can consider this as an error
that needs fixing. I did not even know that this was valid SQL to be honest.

Thanks a lot for your help !

Regards
--
Arnaud

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Charles Clavadetscher 2016-11-17 08:11:53 Re: Request to share information regarding deadlock in postgresql-9.3.6
Previous Message Yogesh Sharma 2016-11-17 07:30:54 Re: Request to share information regarding deadlock in postgresql-9.3.6