On 2022-Jan-06, Amit Langote wrote: > On Thu, Jan 6, 2022 at 7:27 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> > 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. > > 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. Yeah, I realized afterwards that we added tgparentid in 13 only (b9b408c48), so we should only backpatch to that. > > 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? Yes. > Will test that. I looked at the backpatch at the last minute yesterday. The tablecmds.c conflict is easy to resolve, but the one in pg_dump.c is a giant conflict zone that I didn't have time to look closely :-( -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
