Обсуждение: Re: pg_restore - generated column - not populating

On 24.02.21 02:03, Tom Lane wrote:
> [ redirecting to pgsql-bugs ]
> 
> Santosh Udupi <email@hitha.net> writes:
>> Here is my table structure.
> 
> Indeed, this looks pretty busted, both in v13 and HEAD.  It seems that
> pg_dump is not coping well with GENERATED columns attached to a
> partition parent table.  I made the attached script with a bit of
> sample data, loaded it into an empty database, and dumped it.
> The dump is evidently assuming that ALTER TABLE ATTACH PARTITION
> is going to cause the generated-ness of the columns to propagate
> to the children, but it doesn't.  There also seems to be considerable
> confusion about which columns of the child tables should be included
> in the dumped data.
> 
> I suspect this example is revealing bugs in both the backend
> (ATTACH PARTITION ought to take care of this, no?) and pg_dump
> (the backend can't be blamed for pg_dump's choices of columns
> to dump).  Peter?

The backend side of this would be fixed by the proposed 
<https://www.postgresql.org/message-id/ac35da1c-e746-ea19-bfc3-84819a4e907d%40enterprisedb.com> 
(it's the same code for ALTER TABLE ... INHERIT and ATTACH PARTITION).

The pg_dump side can apparently be fixed by adding

diff --git a/src/bin/pg_dump/common.c b/src/bin/pg_dump/common.c
index 1a261a5545..c210883ca3 100644
--- a/src/bin/pg_dump/common.c
+++ b/src/bin/pg_dump/common.c
@@ -585,7 +585,7 @@ flagInhAttrs(DumpOptions *dopt, TableInfo *tblinfo, 
int numTables)
             }

             /* Remove generation expression from child */
-           if (foundGenerated && !dopt->binary_upgrade)
+           if (foundGenerated && !dopt->binary_upgrade && 
!tbinfo->ispartition)
                 tbinfo->attrdefs[j] = NULL;
         }
     }

Looks like this was accidentally broken by the last minor release's 
fixes in this area.

On 26.04.21 15:40, Peter Eisentraut wrote:
>> I suspect this example is revealing bugs in both the backend
>> (ATTACH PARTITION ought to take care of this, no?) and pg_dump
>> (the backend can't be blamed for pg_dump's choices of columns
>> to dump).  Peter?
> 
> The backend side of this would be fixed by the proposed 
> <https://www.postgresql.org/message-id/ac35da1c-e746-ea19-bfc3-84819a4e907d%40enterprisedb.com> 
> (it's the same code for ALTER TABLE ... INHERIT and ATTACH PARTITION).
> 
> The pg_dump side can apparently be fixed by adding
> 
> diff --git a/src/bin/pg_dump/common.c b/src/bin/pg_dump/common.c
> index 1a261a5545..c210883ca3 100644
> --- a/src/bin/pg_dump/common.c
> +++ b/src/bin/pg_dump/common.c
> @@ -585,7 +585,7 @@ flagInhAttrs(DumpOptions *dopt, TableInfo *tblinfo, 
> int numTables)
>             }
> 
>             /* Remove generation expression from child */
> -           if (foundGenerated && !dopt->binary_upgrade)
> +           if (foundGenerated && !dopt->binary_upgrade && 
> !tbinfo->ispartition)
>                 tbinfo->attrdefs[j] = NULL;
>         }
>     }
> 
> Looks like this was accidentally broken by the last minor release's 
> fixes in this area.

Both of these issues have been fixed and will be in the next minor releases.