Re: Assert when executing query on partitioned table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org, Joseph Koshakow <koshy44(at)gmail(dot)com>
Subject: Re: Assert when executing query on partitioned table
Date: 2026-01-22 23:43:54
Message-ID: 3008134.1769125434@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> writes:
> I want to send the patch to Commitfest, so the version changed:
> [1] -> [2] (for cfbot).

I looked this over and concluded that actually, Joseph Koshakow's
proposal upthread is the correct one: just delete the faulty
Assert. If we fall through and let the caller retry, we get
exactly the same behavior as in the non-partition-movement case,
so I'm prepared to accept that behavior as correct. Moreover,
I guess users think so too, because this code is pretty old yet
we've heard no complaints about the production (no-Asserts)
behavior. If we started to throw an error where we hadn't
before, I bet we *would* get complaints.

Also, I realized that we don't really need an injection point
to demonstrate the assertion failure: it's sufficient to make
the other session lock the tuple with SELECT FOR UPDATE before
we start the INSERT. This is good because it's simpler and
it lets the test be back-patched all the way.

Pushed at 4b760a181 et al.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-01-23 00:11:35 Re: ALTER TABLE: warn when actions do not recurse to partitions
Previous Message Chao Li 2026-01-22 23:30:55 Re: tablecmds: reject CLUSTER ON for partitioned tables earlier