Hi Alvaro, On Thu, Jan 6, 2022 at 7:27 AM Alvaro Herrera <alvhe...@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
