Re: [HACKERS] reload-through-the-top-parent switch the partition table - Mailing list pgsql-hackers

From amul sul
Subject Re: [HACKERS] reload-through-the-top-parent switch the partition table
Date
Msg-id CAAJ_b943GkaAdHYiQsAy+4P3oSzgWHmnc8wfk13jGj83V_ZqeA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] reload-through-the-top-parent switch the partition table  (Rushabh Lathia <rushabh.lathia@gmail.com>)
List pgsql-hackers
On Tue, Aug 8, 2017 at 6:18 PM, Rushabh Lathia <rushabh.lathia@gmail.com> wrote:
> Thanks Rajkumar for testing and reporting this.
>
>
> It seems like with we set the numParents and parents only for the
> dumpable objects (flagInhTables()). Current patch relies on the numParents
> and parents to get the root partition TableInfo, but when --schema is been
> specified - it doesn't load those information for the object which is not
> dumpable.
>
> Now one options is:
>
> 1) restrict the --load-via-partition-root to be used with
> the --schema or may be some other options - where we restrict the
> objects.
>
> Consider this, partition root is in schema 'a' and the partition table is in
> schema 'b', if someone specify the --schema b with
> --load-via-partition-root,
> I think we should not do "INSERT INTO a.tab" to load the data (because
> user specified --schema b).
>

+1, this looks cleaner to me.

> 2) fix flagInhTables() to load the numParents and the parents information
> for the partition table (can be checked using ispartition), irrespective of
> whether object is dumpable is true or not.
>
> May be something like:
>
> @@ -322,7 +322,11 @@ flagInhTables(TableInfo *tblinfo, int numTables,
>
>         /* Don't bother computing anything for non-target tables, either */
>         if (!tblinfo[i].dobj.dump)
> +       {
> +           if (tblinfo[i].ispartition)
> +               findParentsByOid(&tblinfo[i], inhinfo, numInherits);
>             continue;
> +       }
>
> I am still looking into this, meanwhile any inputs are welcome.
>

See the note given in the pg_dump document[1] is :

"When -n is specified, pg_dump makes no attempt to dump any other
database objects that the selected schema(s) might depend upon.
Therefore, there is no guarantee that the results of a specific-schema
dump can be successfully restored by themselves into a clean
database."

If we want to follow the same trend then we could simply dump all
partition(ed) belong to a specified schema. In the Rajkumar’s example,
we need to dump partitions belong to schema 'a' (i.e t1_p1 and
t1_p2_p1), and target root for the insert query will be the same table
or the parent belong to the same schema.

Regards,
Amul

[1] https://www.postgresql.org/docs/devel/static/app-pgdump.html



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling