Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

On Tue, 16 Jun 2020 at 11:45, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:

> On Fri, Jun 12, 2020 at 9:22 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > On Wed, Jun 3, 2020 at 12:44 PM Amit Langote <amitlangote09(at)gmail(dot)com>
> wrote:
> > > Are you saying that the planner should take into account the state of
> > > the cursor specified in WHERE CURRENT OF to determine which of the
> > > tables to scan for the UPDATE? Note that neither partition pruning
> > > nor constraint exclusion know that CurrentOfExpr can possibly allow to
> > > exclude children of the UPDATE target.
> >
> > Yes. But it may not be possible to know the value of current of at the
> > time of planning since that need not be a plan time constant. This
> > pruning has to happen at run time.
>
> Good point about not doing anything at planning time.
>
> I wonder if it wouldn't be okay to simply make execCurrentOf() return
> false if it can't find either a row mark or a Scan node in the cursor
> matching the table being updated/deleted from, instead of giving an
> error message? I mean what do we gain by erroring out here instead of
> simply not doing anything? Now, it would be nicer if we could do so
> only if the table being updated/deleted from is a child table, but it
> seems pretty inconvenient to tell that from the bottom of a plan tree
> from where execCurrentOf() is called.
>

A safe guard from a bug where current of is set to wrong table or
something. Quite rare bug but if we can fix the problem itself removing a
safe guard doesn't seem wise.

> The other option would be to have some bespoke "pruning" logic in,
> say, ExecInitModifyTable() that fetches the current active table from
> the cursor and processes only the matching child result relation.

looks better if that works and I don't see a reason why it won't work.

> Or
> maybe wait until we have run-time pruning for ModifyTable, because the
> result relation code restructuring required for that will also be
> something we'd need for this.
>
>
I don't see much difference in the final plan with either options.

--
Best Wishes,
Ashutosh