Feedback-ID: ia2694551:Fastmail
Date: Tue, 23 Jul 2024 19:21:12 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18550: Cross-partition update of a former inheritance
 parent leads to an assertion failure
Message-ID: <202407231721.772zsh7kjvki@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="tzghwpfillwk4o4f"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1061674.1721752542@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202407231721.772zsh7kjvki%40alvherre.pgsql>
Precedence: bulk


--tzghwpfillwk4o4f
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On 2024-Jul-23, Tom Lane wrote:

> I observe that in the case given, t1 still has pg_class.relhassubclass
> true after the ATTACH PARTITION.  Maybe it'd be wise to force that
> false after verifying there are no subclasses?  (I tried fixing it
> manually, and that prevents the assertion crash.)

Yeah, that seems to work.  We can do that essentially for free in
StorePartitionBound(), like in the attached (which was taken in 14).

I'd add Alexander's script as a test too, somewhere near the bottom of
create_table.sql.


If the affected table is a foreign table, it doesn't seem to have the
same problem (I tried using contrib_regression's ft1 as t1 in
Alexander's script).  I suspect that's because we assume somewhere that
foreign tables are not in turn partitioned.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

--tzghwpfillwk4o4f
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
	filename="0001-Reset-relhassubclass-when-attaching-as-a-partition.patch"