Re: pg_dump/pg_restore fail for TAR_DUMP and CUSTOM_DUMP from v94/v95/v96 to v11/master.

From: Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>
Subject: Re: pg_dump/pg_restore fail for TAR_DUMP and CUSTOM_DUMP from v94/v95/v96 to v11/master.
Date: 2019-03-01 11:15:56
Message-ID: CAF1DzPVWJtcQZuJd8usH+S8faT5NNNBV1mBP2VWnLj-GwZwbjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

The Commit 5955d934194c3888f30318209ade71b53d29777f has changed the logic
to avoid dumping creation and comment commands for the public schema.
From v11 onwards, we are using the DUMP_COMPONENT_ infrastructure in
selectDumpableNamespace() to skip the public schema creation.

As reported by Prabhat, if we try to restore the custom/tar dump taken from
v10 and earlier versions, we get the reported error for public schema.
The reason for this error is, when we take custom/tar dump from v10 and
earlier version, it has "CREATE SCHEMA public;" statement and v11 failed to
bypass that as per the current logic.

The plain format does not produces the error in this case, because in all
versions, pg_dump in plain format does not generate that "CREATE SCHEMA
public". In v10 and earlier, we filter out that public schema creation in
_printTocEntry() while pg_dump.

In custom/tar format, pg_dump in V10 and earlier versions generate the
schema creation statement for public schema but again while pg_restore in
same or back branches, it get skipped through same _printTocEntry()
function.

I think we can write a logic in -
1) BulidArchiveDependencies() to avoid dumping creation and comment
commands for the public schema since we do not have DUMP_COMPONENT_
infrastructure in all supported back-branches.
or
2) dumpNamespace() to not include public schema creation.

Thoughts?

Regards,
Suraj

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2019-03-01 11:16:58 Re: Problems with plan estimates in postgres_fdw
Previous Message Peter Eisentraut 2019-03-01 11:13:04 Re: Add exclusive backup deprecation notes to documentation