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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo