Re: Bug in pg_dump

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in pg_dump
Date: 2015-03-01 15:41:31
Message-ID: 20150301154130.GX29780@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Michael,

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> The thing is that we must absolutely wait for *all* the TableInfoData
> of all the extensions to be created because we need to mark the
> dependencies between them, and even my last patch, or even with what
> you are proposing we may miss tracking of FK dependencies between
> tables in different extensions. This has little chance to happen in
> practice, but I think that we should definitely get things right.
> Hence something like this query able to query all the FK dependencies
> with tables in extensions is more useful, and it has no IN clause:

Ah, yes, extensions can depend on each other and so this could
definitely happen. The current issue is around postgis, which by itself
provides three different extensions.

> + appendPQExpBuffer(query,
> + "SELECT conrelid, confrelid "
> + "FROM pg_constraint "
> + "LEFT JOIN pg_depend ON (objid = confrelid) "
> + "WHERE contype = 'f' "
> + "AND refclassid = 'pg_extension'::regclass "
> + "AND classid = 'pg_class'::regclass;");

I'm trying to figure out why this is a left join..?

> >> Subject: [PATCH 2/3] Make prove_check install contents of current directory as well
> >
> > This is really an independent thing, no? I don't see any particular
> > problem with it, for my part.
>
> Yes, that's an independent thing, but my guess is that it would be
> good to have a real test case this time to be sure that this does not
> break again, at least on master where test/modules is an ideal place.

No objection to it, just pointing out that it's independent.

> Attached are updated patches, the fix of pg_dump can be easily
> cherry-picked down to 9.2. For 9.1 things are changed a bit because of
> the way SQL queries are run, still patches are attached for all the
> versions needed. I tested as well the fix down to this version 9.1
> using the test case dump_test.

Will review.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-03-01 15:49:58 Re: mogrify and indent features for jsonb
Previous Message Stephen Frost 2015-03-01 15:14:38 Re: Additional role attributes && superuser review