Re: a misbehavior of partition row movement (?) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: a misbehavior of partition row movement (?)
Date
Msg-id 202201052227.bc4yvvy6lqpb@alvherre.pgsql
Whole thread Raw
In response to Re: a misbehavior of partition row movement (?)  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: a misbehavior of partition row movement (?)
List pgsql-hackers
Pushed 0001.

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.  Also,
psql's describe.c required a small tweak to a version number test.
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.

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.
But there are few ABI changes, maybe we can cope and get all branches
fixes instead of just 15.

What do you think?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos.  Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Bugs in pgoutput.c
Next
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication