Re: Tablesync early exit

2022-04-04 Thread Amit Kapila
On Tue, Apr 5, 2022 at 9:37 AM Peter Smith wrote: > > On Sat, Apr 2, 2022 at 5:17 PM Amit Kapila wrote: > > > > On Fri, Apr 1, 2022 at 1:52 PM Peter Smith wrote: > > > > > > On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila > > > wrote: > > > > > > I think the STATE_CATCHUP guarantees the apply work

Re: Tablesync early exit

2022-04-04 Thread Peter Smith
On Sat, Apr 2, 2022 at 5:17 PM Amit Kapila wrote: > > On Fri, Apr 1, 2022 at 1:52 PM Peter Smith wrote: > > > > On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila wrote: > > > > I think the STATE_CATCHUP guarantees the apply worker must have > > received (or tried to receive) a message. See the previou

Re: Tablesync early exit

2022-04-01 Thread Amit Kapila
On Fri, Apr 1, 2022 at 1:52 PM Peter Smith wrote: > > On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila wrote: > > I think the STATE_CATCHUP guarantees the apply worker must have > received (or tried to receive) a message. See the previous answer. > Sorry, I intend to say till the sync worker has rece

Re: Tablesync early exit

2022-04-01 Thread Peter Smith
On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila wrote: > > On Mon, Aug 30, 2021 at 8:50 AM Peter Smith wrote: > > > > Patch v2 is the same; it only needed re-basing to the latest HEAD. > > > > Why do you think it is correct to exit before trying to receive any > message? I think the STATE_CATCHUP st

Re: Tablesync early exit

2022-03-15 Thread Amit Kapila
On Wed, Mar 16, 2022 at 1:16 AM Greg Stark wrote: > > This patch has been through five CFs without any review. It's a very > short patch and I'm assuming the only issue is that it's not clear > whether it's a good idea or not and there are few developers familiar > with this area of code? > > Amit

Re: Tablesync early exit

2022-03-15 Thread Amit Kapila
On Mon, Aug 30, 2021 at 8:50 AM Peter Smith wrote: > > Patch v2 is the same; it only needed re-basing to the latest HEAD. > Why do you think it is correct to exit before trying to receive any message? How will we ensure whether the apply worker has processed any message? At the beginning of funct

Re: Tablesync early exit

2022-03-15 Thread Greg Stark
This patch has been through five CFs without any review. It's a very short patch and I'm assuming the only issue is that it's not clear whether it's a good idea or not and there are few developers familiar with this area of code? Amit, it looks like you were the one who asked for it to be split of

Re: Tablesync early exit

2021-08-29 Thread Peter Smith
Patch v2 is the same; it only needed re-basing to the latest HEAD. Kind Regards, Peter Smith. Fujitsu Australia v2-0001-Tablesync-early-exit.patch Description: Binary data

Re: Tablesync early exit

2021-03-08 Thread Peter Smith
On Sun, Mar 7, 2021 at 1:33 PM Amit Kapila wrote: > > On Sun, Mar 7, 2021 at 7:26 AM Peter Smith wrote: > > > > Hi hackers. > > > > I propose a small optimization can be added to the tablesync replication > > code. > > > > This proposal (and simple patch) was first discussed here [1]. > > > > It

Re: Tablesync early exit

2021-03-06 Thread Amit Kapila
On Sun, Mar 7, 2021 at 7:26 AM Peter Smith wrote: > > Hi hackers. > > I propose a small optimization can be added to the tablesync replication code. > > This proposal (and simple patch) was first discussed here [1]. > It might be better if you attach your proposed patch to this thread. -- With

Tablesync early exit

2021-03-06 Thread Peter Smith
Hi hackers. I propose a small optimization can be added to the tablesync replication code. This proposal (and simple patch) was first discussed here [1]. Basic idea is the tablesync could/should detect if there is anything to do *before* it enters the apply main loop. Calling process_sync_tables