Subject: Re: pg_restore - generated column - not populating
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Santosh Udupi <email@hitha.net>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>, pgsql-bugs@lists.postgresql.org
References: 
 <CACLRvHZ4a-+SM_159+tcrHdEqxFrG=W4gwTRnwf7Oj0UNj5R2A@mail.gmail.com>
 <9881df8c-f88e-977e-f222-adb04ba1ec80@aklaver.com>
 <CACLRvHY+bD8R-=BWP6U5fBNu0qm_uevhjq6GJekMhPJ1Wyxghw@mail.gmail.com>
 <CACLRvHYOp4uFbJPk_J35oDWs+fv_bpV0LrBQ4dJda_mWKgupUw@mail.gmail.com>
 <CACLRvHYzbfhkg6Z2=HdrKv6YhcipXgnyMhEz0xx1dSALDcn_hQ@mail.gmail.com>
 <ab320161-2511-2559-b190-f71b07b5d089@aklaver.com>
 <CACLRvHaB_mLCygA6AQnc5jh+cBme2A-=Su9oDyO4O20k5ZSKSw@mail.gmail.com>
 <89a62c70-4386-a3ef-f2ea-5e0f448cef11@aklaver.com>
 <CACLRvHaK2tCmXPKSrjKAiQdVV0+zMQ_Gy3onpkFXD4VLnm46Ng@mail.gmail.com>
 <0275a27c-2447-f8e5-489b-d7e419997299@aklaver.com>
 <CACLRvHYQp2BdiS1w+Pt6tHsub=x19-E+L67R2hiJFNwbHY9jYw@mail.gmail.com>
 <3874667.1614101644@sss.pgh.pa.us>
 <CACLRvHaX_6fU_uoEJv=DPNYc4bcYOrmzn+e=dWhW4-com5K9zQ@mail.gmail.com>
 <3877970.1614105611@sss.pgh.pa.us>
 <CACLRvHZHqzVddKL8_v0-cMTezuXnyMAmpYErvJC2gghreVh72g@mail.gmail.com>
 <4007188.1614128586@sss.pgh.pa.us>
 <a9d2893c-bb4a-aadf-c02d-535e752ab2b7@enterprisedb.com>
Message-ID: <ee108f56-82a7-8a9e-21fd-a9cfc280bee3@enterprisedb.com>
Date: Tue, 4 May 2021 14:25:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <a9d2893c-bb4a-aadf-c02d-535e752ab2b7@enterprisedb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/ee108f56-82a7-8a9e-21fd-a9cfc280bee3%40enterprisedb.com>
Precedence: bulk

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.