Re: Truncate in synchronous logical replication failed - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Truncate in synchronous logical replication failed
Date
Msg-id CAA4eK1JYBc3DC+wPmmxFnn_LB_8z0pguDkg5yryTR6+VD+V-RQ@mail.gmail.com
Whole thread Raw
In response to RE: Truncate in synchronous logical replication failed  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Truncate in synchronous logical replication failed  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List pgsql-hackers
On Fri, Apr 23, 2021 at 12:04 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Thursday, April 22, 2021 6:33 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Tue, Apr 20, 2021 at 9:00 AM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> > >
> > > On  Tuesday, April 20, 2021 10:53 AM Ajin Cherian <itsajin@gmail.com>
> > wrote:
> > > >
> > > > I reviewed the patch, ran make check, no issues. One minor comment:
> > > >
> > > > Could you add the comment similar to RelationGetIndexAttrBitmap() on
> > > > why the redo, it's not very obvious to someone reading the code, why
> > > > we are refetching the index list here.
> > > >
> > > > + /* Check if we need to redo */
> > > >
> > > > + newindexoidlist = RelationGetIndexList(relation);
> > > Yeah, makes sense. Fixed.
> >
> > I don't think here we need to restart to get a stable list of indexes as we do in
> > RelationGetIndexAttrBitmap. The reason is here we build the cache entry
> > using a historic snapshot and all the later changes are absorbed while
> > decoding WAL.
> I rechecked this and I agree with this.
> I don't see any problem to remove the redo check.
> Based on this direction, I'll share my several minor comments.
>
> [1] a typo of RelationGetIdentityKeyBitmap's comment
>
> + * This is a special purpose function used during logical replication. Here,
> + * unlike RelationGetIndexAttrBitmap(), we don't a acquire lock on the required
>
> We have "a" in an unnatural place. It should be "we don't acquire...".
>
> [2] suggestion to fix RelationGetIdentityKeyBitmap's comment
>
> + * later changes are absorbed while decoding WAL. Due to this reason, we don't
> + * need to retry here in case of a change in the set of indexes.
>
> I think it's better to use "Because of" instead of "Due to".
> This patch works to solve the deadlock.
>

I am not sure which one is better. I would like to keep it as it is
unless you feel strongly about point 2.

> [3] wrong comment in RelationGetIdentityKeyBitmap
>
> +       /* Save some values to compare after building attributes */
>
> I wrote this comment for the redo check
> that has been removed already. We can delete it.
>
> [4] suggestion to remove local variable relreplindex in RelationGetIdentityKeyBitmap
>
> I think we don't need relreplindex.
> We can just pass relaton->rd_replidindex to RelationIdGetRelation().
> There is no more reference of the variable.
>
> [5] suggestion to fix the place to release indexoidlist
>
> I thought we can do its list_free() ealier,
> after checking if there is no indexes.
>

Hmm, why? If there are no indexes then we wouldn't have allocated any memory.

> [6] suggestion to remove period in one comment.
>
> +       /* Quick exit if we already computed the result. */
>
> This comes from RelationGetIndexAttrBitmap (and my posted versions)
> but I think we can remove the period to give better alignment shared with other comments in the function.
>

Can you please update the patch except for the two points to which I
responded above?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "wangyukun@fujitsu.com"
Date:
Subject: fix a comment
Next
From: Amul Sul
Date:
Subject: Re: fix a comment