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 CAA4eK1+DJ9N3TUHZ7AFhDQECbpM4JYHWO=N1rDUJqyYGqx3EBA@mail.gmail.com
Whole thread Raw
In response to Re: Time delayed LR (WAS Re: logical replication restrictions)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Time delayed LR (WAS Re: logical replication restrictions)
List pgsql-hackers
On Tue, Jan 24, 2023 at 8:35 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> Sorry, I forgot to write one comment.
>
> At Tue, 24 Jan 2023 11:45:35 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
>
> +       /* Should we delay the current transaction? */
> +       if (finish_ts)
> +               maybe_delay_apply(xid, finish_ts);
> +
>         if (!am_parallel_apply_worker())
>                 maybe_start_skipping_changes(lsn);
>
> It may not give actual advantages, but isn't it better that delay
> happens after skipping?
>

If we go with the order you are suggesting then the LOGs will appear
as follows when we are skipping the transaction:

"logical replication starts skipping transaction at LSN ..."
"time-delayed replication for txid %u, min_apply_delay = %lld ms,
Remaining wait time: ..."

Personally, I would prefer the above LOGs to be in reverse order as it
doesn't make much sense to me to first say that we are skipping
changes and then say the transaction is delayed. What do you think?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Dilip Kumar
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum