public inbox for [email protected]
help / color / mirror / Atom feedFrom: Hayato Kuroda (Fujitsu) <[email protected]>
To: 'Amit Kapila' <[email protected]>
To: Takamichi Osumi (Fujitsu) <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Euler Taveira <[email protected]>
Cc: Melih Mutlu <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Marcos Pegoraro <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Peter Smith <[email protected]>
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Date: Mon, 12 Dec 2022 07:34:49 +0000
Message-ID: <TYAPR01MB58669394A67F2340B82E42D1F5E29@TYAPR01MB5866.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAA4eK1+2tbyjk12rpG=OYYUdhiBauHXJ-u1WZtpQ2viMCPBMdA@mail.gmail.com>
References: <CAB-JLwYOYwL=XTyAXKiH5CtM_Vm8KjKh7aaitCKvmCh4rzr5pQ@mail.gmail.com>
<CAA4eK1JW+_Pff3TOaBqbOqn-LbMT2kj2bpw-a88ZSTdbTZ-aMg@mail.gmail.com>
<CAB-JLwas_=FGr8bXKD7K6g0=RDUFuYU71TLLGTsQ-DTRNpq1QQ@mail.gmail.com>
<CAA4eK1KSBGrLKR63iS38Bkvjq6fBCWzbuD6R15kEWdmd8aj3mw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAGPVpCQgE1e0JQFHbxSpfj82HQfAqGmhG=yru3mX2tcmbfqHYA@mail.gmail.com>
<[email protected]>
<TYWPR01MB83628B9AE512989DCEC67F3FED659@TYWPR01MB8362.jpnprd01.prod.outlook.com>
<[email protected]>
<CALDaNm0aZeUb7LmdSc9aKkNDNdhabWEakB5bOT3bogrFAaO+_Q@mail.gmail.com>
<CAA4eK1J6xLUJNR1tXEidnpWFkX8afF40MCT4x7vgojKXBtwZMg@mail.gmail.com>
<CAA4eK1+0HciGUr8jqOBDcQFiEBU9qErYZraGskj_tQ1bGc2Ytw@mail.gmail.com>
<TYAPR01MB5866E747C3C5C1D99F88D179F5059@TYAPR01MB5866.jpnprd01.prod.outlook.com>
<CAA4eK1KMKt+_Qjw=WYtDXUg-tHr6hSFQZTZFVPrUZ=suK2j5kA@mail.gmail.com>
<TYAPR01MB58668CC2AFEDD8BE77C07BE6F5059@TYAPR01MB5866.jpnprd01.prod.outlook.com>
<CAA4eK1JJFpgqE0ehAb7C9YFkJ-Xe-W1ZUPZptEfYjNJM4G-sLA@mail.gmail.com>
<CAA4eK1Lj+-1g2vWfz31sSsXpZ+Gr7oq+qsiFURWTKyEoJP9T+A@mail.gmail.com>
<TYCPR01MB8373FA10EB2DB2BF8E458604ED1B9@TYCPR01MB8373.jpnprd01.prod.outlook.com>
<CAA4eK1+2tbyjk12rpG=OYYUdhiBauHXJ-u1WZtpQ2viMCPBMdA@mail.gmail.com>
Dear Amit,
This is a reply for later part of your e-mail.
> > (2) About the timeout issue
> >
> > When having a look at the physical replication internals,
> > it conducts sending feedback and application of delay separately on different
> processes.
> > OTOH, the logical replication needs to achieve those within one process.
> >
> > When we want to apply delay and avoid the timeout,
> > we should not store all the transactions data into memory.
> > So, one approach for this is to serialize the transaction data and after the delay,
> > we apply the transactions data.
> >
>
> It is not clear to me how this will avoid a timeout.
At first, the reason why the timeout occurs is that while delaying the apply
worker neither reads messages from the walsender nor replies to it.
The worker's last_recv_timeout will be not updated because it does not receive
messages. This leads to wal_receiver_timeout. Similarly, the walsender's
last_processing will be not updated and exit due to the timeout because the
worker does not reply to upstream.
Based on the above, we thought that workers must receive and handle messages
evenif they are delaying applying transactions. In more detail, workers must
iterate the outer loop in LogicalRepApplyLoop().
If workers receive transactions but they need to delay applying, they must keep
messages somewhere. So we came up with the idea that workers serialize changes
once and apply later. Our basic design is as follows:
* All transactions areserialized to files if min_apply_delay is set to non-zero.
* After receiving the commit message and spending time, workers reads and
applies spooled messages
> > However, this means if users adopt this feature,
> > then all transaction data that should be delayed would be serialized.
> > We are not sure if this sounds a valid approach or not.
> >
> > One another approach was to divide the time of delay in apply_delay() and
> > utilize the divided time for WaitLatch and sends the keepalive messages from
> there.
> >
>
> Do we anytime send keepalive messages from the apply side? I think we
> only send feedback reply messages as a response to the publisher's
> keep_alive message. So, we need to do something similar for this if
> you want to follow this approach.
Right, and the above mechanism is needed for workers to understand messages
and send feedback replies as a response to the publisher's keepalive message.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
view thread (93+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
In-Reply-To: <TYAPR01MB58669394A67F2340B82E42D1F5E29@TYAPR01MB5866.jpnprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox