ADBDEV-5169: Add the ability to backup partitions whose parent is in the extension

[KnightMurloc]

Add the ability to backup partitions whose parent is in the extension

In 7X, if there was a partition in the database whose parent was in the
extension, then the backup attempt would have ended in panic. This was due to
the fact that when receiving the names of the parent tables, the tables in the
extension were filtered out, which led to a reference to nil when creating DDL
for ATTACH PARTITION.

This patch fixes the panic by removing the filtering of tables in the extension
for 7X.

This patch also adds the ability to backup such partitions in 7X. For 6X and
earlier, the old behavior was left in order not to violate the established
behavior.

There is a situation when, after a backup of the database with such partitions,
an error may appear when restoring. This can happen if data is added to the
default partition in the extension creation script. Then, during the restore,
when creating a new partition, the default partition constraints will change,
and if the data in the default partition does not meet the new constraints, an
error will appear. If such a situation occurs, problematic partitions should be
excluded using --exclude-table, where a root partition is specified. There is a
test for this case: "allows the user to exclude partitions that hinder restore
if the default partition in the extension contains data".

[RekGRpth]

Why did you removed ExtensionFilterClause for 5X and 6X?

[KnightMurloc]

in 6X, we can also lose inheritance during backup if the parent is in the extension.

[RekGRpth]

Are you sure it is good idea to put where in condition variable?

[KnightMurloc]

Since we have no other conditions, WHERE is needed only in the case of this filter.

Mistake

[InnerLife0]

I have some new questions/comments.

1. If I understand this right, the behavior of gpbackup in prism of default partition backup is different in 6x and 7x. I miss explanation of this difference in PR and commit description.

2. Next, I have the following case.
   Extension script:

create schema if not exists test;
create table test.ao1 (a int, b int, c text) 
with (appendonly=true) 
distributed by (a)
partition by range (b) (start (1) end (10) every (5));
insert into test.ao1 select i,i,i from generate_series(1,9) i;

User script:

alter table test.ao1 add partition test_part start(10) end(15);
insert into test.ao1 select i,i,i from generate_series(10,14) i;

When I try to backup this using the latest version on 6x, the user partition is not backed up. It seems that previous version of patch backed up this partition. Is it an expected behavior?

3. Some of my old review messages were not taken into account.

4. It's better to answer to reviewer comments. Otherwise, I should check all the points by myself without understanding was my comment useful and taken into account.

[KnightMurloc]

1. Actually, the difference is not that big between 6X and 7X. In 6X, we to do SPLIT the default partition in case it is in the table. In 7X, we need to do SPLIT only if the default partition contains data related to the new partition. Therefore, in 6X it is important for us to create a default partition the last ones, and in 7X the order is not important to us.
2. Has the --leaf-partition-data flag been set? if not, then skipping such partitions is the expected behavior. I checked with me if the --leaf-partition-data flag is set, then the user partition will be backed up.

[InnerLife0]

1. Actually, the difference is not that big between 6X and 7X. In 6X, we to do SPLIT the default partition in case it is in the table. In 7X, we need to do SPLIT only if the default partition contains data related to the new partition. Therefore, in 6X it is important for us to create a default partition the last ones, and in 7X the order is not important to us.
2. Has the --leaf-partition-data flag been set? if not, then skipping such partitions is the expected behavior. I checked with me if the --leaf-partition-data flag is set, then the user partition will be backed up.

1. You already have a good point in description about --leaf-partition-data in 6x. We should highlight all the differences between 6x and 7x in the same way. If we have some cases in which we can't create backup script properly (e.g. SPLIT except ADD to table with default partition) then we should highlight them too. Description should contain a full picture of our desired behavior.
2. I can't restore my past test scripts, but it seems you are right. Sorry.

I also want to check how query plans were changed, but will do this later.

[InnerLife0]

We can backup partitions that are outside the extension if no data is added to the default partition in the extension creation script, otherwise we will get an error when restoring from the backup. Because when adding a new partition, the constants on the default partition change, and if the data in the partition does not meet the new constraints, we will get an error. If such a situation occurs during restore, you should exclude problematic partitions using --exclude-table, where you need to specify the name of the root partition.

The updated explanation looks too informal and contains a lot of pronounces.
Some sentences can be changed. For example:
We can backup partitions -> partitions can be backed up
we will get an error -> the error occurs
you should exclude problematic partitions -> partitions should be excluded (or use a past tense if it was before the patch and describe how it works now)
the constants on the default partition change -> (here I just don't understand what you mean)

Please format PR message according to points in our wiki.

[KnightMurloc]

the constants on the default partition change -> (here I just don't understand what you mean)

when we create a partitioned table with a default partition, a constraint is added to it:

Partition constraint: (NOT ((a IS NOT NULL) AND (((a >= 0) AND (a < 1)) OR ((a >= 1) AND (a < 2)) OR ((a >= 2) AND (a < 3)))))

simplified looks like this:

NOT ((a IS NOT NULL) AND (a = 0 OR a = 1 OR a = 2))

if we add a partition for a = 1. the constraint will change to:

NOT ((a IS NOT NULL) AND (a = 0 OR a = 2))

And if the default partition contains rows with a = 1, we will get an error.

[InnerLife0]

Overall ok, but the PR description should be updated to highlight current situation, what abilities current code missed and what was changed to achieve them (including difference in 6x and 7x behavior). Already explained case is just a special case, but it can be linked with existed test.