Re: a misbehavior of partition row movement (?)

On Tue, Mar 23, 2021 at 6:27 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> Sawada-san,
>
> On Wed, Mar 10, 2021 at 4:51 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > I looked at the 0001 patch and here are random comments. Please ignore
> > a comment if it is already discussed.
>
> Thanks a lot for the review and sorry for the delay in replying.

No problem. Sorry for the late reply too.

> > Or is this change really needed? This change added one condition
> > "tgparentid = 0" but IIUC I think triggers that are NOT tgisinternal
> > are always tgparentid = 0. Also, it seems it is true both before and
> > after this patch.
>
> Actually, as noted in the commit message, I'm intending to change
> tgisnternal to only be true for triggers generated by foreign keys and
> no longer for partitions' user-defined triggers that are inherited.
> So whereas NOT tgisnternal would suffice to exclude partitions'
> inherited triggers before, that would no longer be the case with this
> patch; AND tgparentid = 0 will be needed for that.

Understood.

>
> Actually, I found a big hole in my assumptions around deferrable
> foreign constraints, invalidating the approach I took in 0002 to use a
> query-lifetime tuplestore to record root parent tuples. I'm trying to
> find a way to make the tuplestore transaction-lifetime so that the
> patch still works.
>
> In the meantime, I'm attaching an updated set with 0001 changed per
> your comments.

0001 patch conflicts with 71f4c8c6f74. Could you please rebase the patchset?

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/