Hi Alvaro,
On Thu, Jan 6, 2022 at 7:27 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Pushed 0001.
Thank you.
> I had to adjust the query used in pg_dump; you changed the attribute
> name in the query used for pg15, but left unchanged the one for older
> branches, so pg_dump failed for all branches other than 15.
Oops, should've tested that.
> Also,
> psql's describe.c required a small tweak to a version number test.
Ah, yes -- 15, not 14 anymore.
> https://github.com/alvherre/postgres/commit/3451612e0fa082d3ec953551c6d25432bd725502
>
> Thanks! What was 0002 is attached, to keep cfbot happy. It's identical
> to your v11-0002.
>
> I have pushed it thinking that we would not backpatch any of this fix.
> However, after running the tests and realizing that I didn't need an
> initdb for either patch, I wonder if maybe the whole series *is*
> backpatchable.
Interesting thought.
We do lack help from trigger.c in the v12 branch in that there's no
Trigger.tgisclone, which is used in a couple of places in the fix. I
haven't checked how big of a deal it would be to back-port
Trigger.tgisclone to v12, but maybe that's doable.
> There is one possible problem, which is that psql and pg_dump would need
> testing to verify that they work decently (i.e. no crash, no
> misbehavior) with partitioned tables created with the original code.
I suppose you mean checking if the psql and pg_dump after applying
*0001* work sanely with partitioned tables defined without 0001?
Will test that.
> But there are few ABI changes, maybe we can cope and get all branches
> fixes instead of just 15.
>
> What do you think?
Yeah, as long as triggers are configured as required by the fix, and
that would be ensured if we're able to back-patch 0001 down to v12, I
suppose it would be nice to get this fixed down to v12.
--
Amit Langote
EDB: http://www.enterprisedb.com