Re: Query regarding selectDumpableExtension()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: amul sul <sulamul(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query regarding selectDumpableExtension()
Date: 2016-10-31 13:18:31
Message-ID: 17322.1477919911@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

amul sul <sulamul(at)gmail(dot)com> writes:
> On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> There's a comment in dumpExtension() that explains it.

> Let me explain the case I'm trying to tackle. I have two old dump
> data, each of them have couple objects depend on plpgsql. I have
> restored first dump and trying restore second dump using 'pg_restore
> -c' command, it is failing with following error:
> ERROR: cannot drop extension plpgsql because other objects depend on it

This is hardly specific to extensions. If you try a restore with -c into
a database that has other random objects besides what's in the dump, you
could get errors from
* dropping tables that are referenced by foreign keys from tables not
known in the dump
* dropping functions that are used in views not known in the dump
* dropping operators or opclasses used by indexes not known in the dump
etc etc.

> Works well without '-c' option, but that what not a general solution, IMHO.

The general solution is either don't restore into a database containing
unrelated objects, or be prepared to ignore errors from the DROP commands.
The extension case actually works more smoothly than most of the others.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-31 13:21:19 Re: Overlook in 2bd9e412?
Previous Message Robert Haas 2016-10-31 13:09:43 Re: Proposal : For Auto-Prewarm.