public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kirill Reshke <[email protected]>
To: Tom Lane <[email protected]>
Cc: Tender Wang <[email protected]>
Cc: jian he <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Amit Langote <[email protected]>
Subject: Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error
Date: Thu, 30 Oct 2025 10:31:38 +0500
Message-ID: <CALdSSPi7udsgQg3PUG=Z4+-9pRg8wT3HkDvTgYvtg30xNWQ9OA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CACJufxF9FcuYe8XOuWLgWK77HCUHpOc6+7+NkktFFNmzw15jKg@mail.gmail.com>
<CAHewXN=vF5d9O4R3+iUwLqEaP7pb8iYAN_e3vEE_p5sJHofn7w@mail.gmail.com>
<[email protected]>
On Thu, 30 Oct 2025 at 10:08, Tom Lane <[email protected]> wrote:
>
> It's surely pretty accidental (and arguably not desirable)
> if "DELETE FROM pt WHERE false" doesn't fail the same way.
>
> Now, I agree that it's not great if you instead get an
> internal error like "could not find junk ctid column".
> But that smells to me like error checks being applied in
> the wrong order rather than something fundamentally wrong.
>
> I didn't look at the proposed patch yet.
>
> regards, tom lane
I wrote:
> But I also wonder if Jian's fix fixed the right thing. Should we
> instead fail in the planning phase with a more user-friendly error
> message? This will be a regression though, because 'DELETE FROM
> file_fdw_table WHERE false' will no longer work...
On the second thought, I doubt anyone will get unhappy with 'DELETE
FROM file_fdw_table WHERE false' stop working
Alexander wrote:
> On 86dc9005~1 or with enable_partition_pruning = 'on', EXPLAIN outputs the
> query plan and "DELETE FROM pt WHERE false;" completes with no error.
So, behaviour was wrong both before and after 86dc9005, just in different ways.
On head, we get an error about junk columns, because without partition
pruning, we derive the result relation as 'pt', not its partition
'p1', which is correct I believe. But with 'p1' as result relation,
we (correctly) error out in ExecInitModifyTable while with 'pt' we
don't.
So, error checks are applied, order is not wrong, but rather checks
are not full enough? I mean, we I believe we need to execute
CheckValidResultRel against all partitions in ExecInitModifyTable, at
least when no partition pruning has been performed
--
Best regards,
Kirill Reshke
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error
In-Reply-To: <CALdSSPi7udsgQg3PUG=Z4+-9pRg8wT3HkDvTgYvtg30xNWQ9OA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox