Re: Time delayed LR (WAS Re: logical replication restrictions) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Time delayed LR (WAS Re: logical replication restrictions)
Date
Msg-id CAA4eK1JHy8edLMHHz8pWtxJ8HoCmB8k7LkJKZfRU6aOHHYG3eA@mail.gmail.com
Whole thread Raw
In response to Re: Time delayed LR (WAS Re: logical replication restrictions)  (Peter Smith <smithpb2250@gmail.com>)
Responses RE: Time delayed LR (WAS Re: logical replication restrictions)
Re: Time delayed LR (WAS Re: logical replication restrictions)
List pgsql-hackers
On Tue, Jan 24, 2023 at 12:44 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Tue, Jan 24, 2023 at 5:58 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Jan 24, 2023 at 8:15 AM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > >
> > > > Attached the updated patch v19.
> > >
> > > + maybe_delay_apply(TransactionId xid, TimestampTz finish_ts)
> > >
> > > I look this spelling strange.  How about maybe_apply_delay()?
> > >
> >
> > +1.
>
> It depends on how you read it. I read it like this:
>
> maybe_delay_apply === means "maybe delay [the] apply"
> (which is exactly what the function does)
>
> versus
>
> maybe_apply_delay === means "maybe [the] apply [needs a] delay"
> (which is also correct, but it seemed a more awkward way to say it IMO)
>

This matches more with GUC and all other usages of variables in the
patch. So, I still prefer the second one.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Dmitry Dolgov
Date:
Subject: Re: Schema variables - new implementation for Postgres 15 (typo)