Dear hackers,
> At PGcon and other places we have discussed the time-delayed logical
> replication,
> but now we have understood that there are no easy ways. Followings are our
> analysis.
At this point, I have not planned to develop the PoC anymore, unless better idea
or infrastructure will
Dear hackers,
At PGcon and other places we have discussed the time-delayed logical
replication,
but now we have understood that there are no easy ways. Followings are our
analysis.
# Abstract
To implement the time-dealyed logical replication for more proper approach,
the worker must serialize
Dear Amit,
Thank you for giving suggestions.
> > Dear hackers,
> >
> > I rebased and refined my PoC. Followings are the changes:
> >
>
> 1. Is my understanding correct that this patch creates the delay files
> for each transaction? If so, did you consider other approaches such as
> using one
On Fri, May 12, 2023 at 10:33 AM Amit Kapila wrote:
>
> On Fri, May 12, 2023 at 7:38 AM Masahiko Sawada wrote:
> >
> > On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> > >
> > > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > > wrote:
> > > >
> > > > Dear hackers,
> > > >
> > >
On Fri, May 12, 2023 at 7:38 AM Masahiko Sawada wrote:
>
> On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> >
> > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear hackers,
> > >
> > > I rebased and refined my PoC. Followings are the changes:
> > >
> >
> >
On Fri, May 12, 2023 at 12:48 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > Overall, I think such an approach can address comments by Sawada-San
> > > [1] but not sure if Sawada-San or others have any better ideas to
> > > achieve this feature. It would be good to see what others think of
> > > this
Dear Amit, Sawada-san,
Thank you for replying!
> On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
> >
> > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear hackers,
> > >
> > > I rebased and refined my PoC. Followings are the changes:
> > >
> >
> > 1. Is my
On Thu, May 11, 2023 at 2:04 PM Amit Kapila wrote:
>
> On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear hackers,
> >
> > I rebased and refined my PoC. Followings are the changes:
> >
>
> 1. Is my understanding correct that this patch creates the delay files
> for
On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> I rebased and refined my PoC. Followings are the changes:
>
1. Is my understanding correct that this patch creates the delay files
for each transaction? If so, did you consider other approaches such as
using one
Dear Amit-san, Bharath,
Thank you for giving your opinion!
> Some of the other solutions like MySQL also have this feature. See
> [2], you can also read the other use cases in that article. It seems
> pglogical has this feature and there is a customer demand for the same
> [3]
Additionally, the
On Wed, May 10, 2023 at 5:35 PM Bharath Rupireddy
wrote:
>
> On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear hackers,
> >
> > I rebased and refined my PoC. Followings are the changes:
>
> Thanks.
>
> Apologies for being late here. Please bear with me if I'm
On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> I rebased and refined my PoC. Followings are the changes:
Thanks.
Apologies for being late here. Please bear with me if I'm repeating
any of the discussed points.
I'm mainly trying to understand the production
Dear hackers,
Based on the discussion Sawada-san pointed out[1] that the current approach of
logical time-delayed avoids recycling WALs, I'm planning to close the CF entry
once.
This or the forked thread will be registered again after deciding on the
alternative
approach. Thank you very much
On Thu, Mar 9, 2023 at 2:56 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 9 Mar 2023 11:00:46 +0530, Amit Kapila
> wrote in
> > On Wed, Mar 8, 2023 at 9:20 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart
> > > wrote:
> > > >
> > >
> > > > IMO the current
At Thu, 9 Mar 2023 11:00:46 +0530, Amit Kapila wrote
in
> On Wed, Mar 8, 2023 at 9:20 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart
> > wrote:
> > >
> >
> > > IMO the current set of
> > > trade-offs (e.g., unavoidable bloat and WAL buildup) would make this
On Wed, Mar 8, 2023 at 9:20 AM Masahiko Sawada wrote:
>
> On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart
> wrote:
> >
>
> > IMO the current set of
> > trade-offs (e.g., unavoidable bloat and WAL buildup) would make this
> > feature virtually unusable for a lot of workloads, so it's probably
On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart wrote:
>
> On Mon, Mar 06, 2023 at 07:27:59PM +0300, Önder Kalacı wrote:
> > On the other hand, we already have a similar problem with
> > recovery_min_apply_delay combined with hot_standby_feedback [1].
> > So, that probably is an acceptable
On Mon, Mar 06, 2023 at 07:27:59PM +0300, Önder Kalacı wrote:
> On the other hand, we already have a similar problem with
> recovery_min_apply_delay combined with hot_standby_feedback [1].
> So, that probably is an acceptable trade-off for the pgsql-hackers.
> If you use this feature, you should
Hi all,
Thanks for working on this.
> I imagine that a typical use case would be to set min_send_delay to
> several hours to days. I'm concerned that it could not be an
> acceptable trade-off for many users that the system cannot collect any
> garbage during that.
>
I'm not too worried about
On Thu, Mar 2, 2023 at 1:07 PM Amit Kapila wrote:
>
> On Thu, Mar 2, 2023 at 7:38 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > >
> > > > Apart from a bad-use case example I mentioned, in general, piling up
> > > > WAL files due
> Yeah, min_send_delay and max_slots_wal_keep_size should be easily tunable
> because
> the appropriate value depends on the enviroment and workload.
> However, pg_replication_slots.pg_replication_slots cannot show the exact amout
> of WALs,
> so it may not suitable for tuning. I think user can
Dear Amit,
> Fair point but I think the current comment should explain why we are
> doing something different here. How about extending the existing
> comments to something like: "If we've requested to shut down, exit the
> process. This is unlike handling at other places where we allow
>
Dear Vignesh,
Thank you for reviewing! New version can be available at [1].
> 1) Currently we have added the delay during the decode of commit,
> while decoding the commit walsender process will stop decoding any
> further transaction until delay is completed. There might be a
> possibility that
Dear Peter,
Thank you for reviewing! PSA new version.
> 1.
> Nitpick. The new text is jagged-looking. It should wrap at ~80 chars.
Addressed.
>
> 2.
> 2. Another reason is for that parallel streaming, the transaction will be
> opened
> immediately by the parallel apply worker. Therefore, if
Dear Amit, Sawada-san,
> I think Kuroda-San wants to emit a WARNING at the time of CREATE
> SUBSCRIPTION. But it won't be possible to emit a WARNING at the time
> of ALTER SUBSCRIPTION. Also, as you say if the user later changes the
> value of max_slot_wal_keep_size, then even if we issue
On Thu, Mar 2, 2023 at 7:38 AM Masahiko Sawada wrote:
>
> On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > >
> > > Apart from a bad-use case example I mentioned, in general, piling up
> > > WAL files due to the replication slot has many bad effects on the
> > > system. I'm
On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thank you for giving your consideration!
>
> > > We have documented at least one such case
> > > already where during Drop Subscription, if the network is not
> > > reachable then also, a similar problem can
On Tue, 28 Feb 2023 at 21:21, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit,
>
> > Few comments:
>
> Thank you for reviewing! PSA new version.
Thanks for the updated patch, few comments:
1) Currently we have added the delay during the decode of commit,
while decoding the commit walsender process
Dear Sawada-san,
Thank you for giving your consideration!
> > We have documented at least one such case
> > already where during Drop Subscription, if the network is not
> > reachable then also, a similar problem can happen and users need to be
> > careful about it [1].
>
> Apart from a
On Wed, Mar 1, 2023 at 10:57 AM Masahiko Sawada wrote:
>
> On Wed, Mar 1, 2023 at 1:55 PM Amit Kapila wrote:
> >
>
> > Won't a malicious user can block the
> > replication in other ways as well and let the publisher stall (or
> > crash the publisher) even without setting min_send_delay?
On Wed, Mar 1, 2023 at 1:55 PM Amit Kapila wrote:
>
> On Wed, Mar 1, 2023 at 8:18 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 1, 2023 at 12:51 AM Hayato Kuroda (Fujitsu)
> > wrote:
> >
> > Thinking of side effects of this feature (no matter where we delay
> > applying the changes), on the
On Tue, Feb 28, 2023 at 9:21 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > 1.
> > + /*
> > + * If we've requested to shut down, exit the process.
> > + *
> > + * Note that WalSndDone() cannot be used here because the delaying
> > + * changes will be sent in the function.
> > + */
> > + if
On Wed, Mar 1, 2023 at 8:18 AM Masahiko Sawada wrote:
>
> On Wed, Mar 1, 2023 at 12:51 AM Hayato Kuroda (Fujitsu)
> wrote:
>
> Thinking of side effects of this feature (no matter where we delay
> applying the changes), on the publisher, vacuum cannot collect garbage
> and WAL cannot be recycled.
On Wed, Mar 1, 2023 at 8:06 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 28 Feb 2023 08:35:11 +0530, Amit Kapila
> wrote in
> > On Tue, Feb 28, 2023 at 8:14 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Mon, 27 Feb 2023 14:56:19 +0530, Amit Kapila
> > > wrote in
> > > > The one difference w.r.t
On Wed, Mar 1, 2023 at 12:51 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit,
>
> > Few comments:
>
> Thank you for reviewing! PSA new version.
> Note that the starting point of delay for 2PC was not changed,
> I think it has been under discussion.
>
> > 1.
> > + /*
> > + * If we've requested to
At Tue, 28 Feb 2023 08:35:11 +0530, Amit Kapila wrote
in
> On Tue, Feb 28, 2023 at 8:14 AM Kyotaro Horiguchi
> wrote:
> >
> > At Mon, 27 Feb 2023 14:56:19 +0530, Amit Kapila
> > wrote in
> > > The one difference w.r.t recovery_min_apply_delay is that here we will
> > > hold locks for the
Here are some review comments for v9-0001, but these are only very trivial.
==
Commit Message
1.
Nitpick. The new text is jagged-looking. It should wrap at ~80 chars.
~~~
2.
2. Another reason is for that parallel streaming, the transaction will be opened
immediately by the parallel apply
Dear Amit,
> Few comments:
Thank you for reviewing! PSA new version.
Note that the starting point of delay for 2PC was not changed,
I think it has been under discussion.
> 1.
> + /*
> + * If we've requested to shut down, exit the process.
> + *
> + * Note that WalSndDone() cannot be used here
On Mon, Feb 27, 2023 at 2:21 PM Hayato Kuroda (Fujitsu)
wrote:
>
Few comments:
1.
+ /*
+ * If we've requested to shut down, exit the process.
+ *
+ * Note that WalSndDone() cannot be used here because the delaying
+ * changes will be sent in the function.
+ */
+ if (got_STOPPING)
+ {
+
On Tue, Feb 28, 2023 at 8:14 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 27 Feb 2023 14:56:19 +0530, Amit Kapila
> wrote in
> > The one difference w.r.t recovery_min_apply_delay is that here we will
> > hold locks for the duration of the delay which didn't seem to be a
> > good idea. This will also
At Mon, 27 Feb 2023 14:56:19 +0530, Amit Kapila wrote
in
> The one difference w.r.t recovery_min_apply_delay is that here we will
> hold locks for the duration of the delay which didn't seem to be a
> good idea. This will also probably lead to more bloat as we will keep
> transactions open for
On Mon, Feb 27, 2023 at 1:50 PM Masahiko Sawada wrote:
>
> On Mon, Feb 27, 2023 at 3:34 PM Amit Kapila wrote:
> >
> > > ---
> > > Why do we not to delay sending COMMIT PREPARED messages?
> > >
> >
> > I think we need to either add delay for prepare or commit prepared as
> > otherwise, it will
Dear Sawada-san, Amit,
Thank you for reviewing!
> + *
> + * LOGICALREP_PROTO_MIN_SEND_DELAY_VERSION_NUM is the minimum
> protocol version
> + * with support for delaying to send transactions. Introduced in PG16.
> */
> #define LOGICALREP_PROTO_MIN_VERSION_NUM 1
> #define
On Mon, Feb 27, 2023 at 3:34 PM Amit Kapila wrote:
>
> On Mon, Feb 27, 2023 at 11:11 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Feb 23, 2023 at 9:10 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Thank you for reviewing! PSA new version.
> > >
> > >
> >
> > Thank you for updating the
Dear Amit,
> I was trying to think if there is any better way to implement the
> newly added callback (WalSndDelay()) but couldn't find any. For
> example, one idea I tried to evaluate is whether we can merge it with
> the existing callback WalSndUpdateProgress() or maybe extract the part
> other
On Mon, Feb 27, 2023 at 11:11 AM Masahiko Sawada wrote:
>
> On Thu, Feb 23, 2023 at 9:10 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Thank you for reviewing! PSA new version.
> >
> >
>
> Thank you for updating the patch. Here are some comments on v7 patch:
>
> + *
> + *
On Thu, Feb 23, 2023 at 5:40 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Thank you for reviewing! PSA new version.
>
I was trying to think if there is any better way to implement the
newly added callback (WalSndDelay()) but couldn't find any. For
example, one idea I tried to evaluate is whether we can
On Thu, Feb 23, 2023 at 9:10 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shi,
>
> Thank you for reviewing! PSA new version.
>
> > + elog(DEBUG2, "time-delayed replication for txid %u, delay_time
> > = %d ms, remaining wait time: %ld ms",
> > + ctx->write_xid, (int)
Dear Shi,
Thank you for reviewing! PSA new version.
> + elog(DEBUG2, "time-delayed replication for txid %u, delay_time
> = %d ms, remaining wait time: %ld ms",
> + ctx->write_xid, (int) ctx->min_send_delay,
> + remaining_wait_time_ms);
>
> I
On Wed, Feb 22, 2023 9:48 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> Thank you for reviewing! PSA new version.
>
Thanks for your patch. Here is a comment.
+ elog(DEBUG2, "time-delayed replication for txid %u, delay_time
= %d ms, remaining wait time: %ld ms",
+
Patch v6 LGTM.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
Dear Amit,
Thank you for reviewing! PSA new version.
> I think it would be better to say: "The minimum delay, in
> milliseconds, by the publisher before sending all the changes". If you
> agree then similar change is required in below comment as well:
> + /*
> + * The minimum delay, in
On Tue, Feb 21, 2023 at 1:28 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > doc/src/sgml/catalogs.sgml
> >
> > 4.
> > +
> > +
> > + subminsenddelay int4
> > +
> > +
> > + The minimum delay, in milliseconds, by the publisher to send changes
> > +
> > +
> >
>
Dear Peter,
Thank you for reviewing! PSA new version.
> 1.
> The other possibility was to apply the delay at the end of the parallel apply
> transaction but that would cause issues related to resource bloat and
> locks being
> held for a long time.
>
> ~
>
> The reply [1] for review comment #2
Here are some very minor review comments for the patch v4-0001
==
Commit Message
1.
The other possibility was to apply the delay at the end of the parallel apply
transaction but that would cause issues related to resource bloat and
locks being
held for a long time.
~
The reply [1] for
Dear Amit,
Thank you for commenting!
> > 8.
> > +
> > + The delay is effective only when the initial table
> > synchronization
> > + has been finished and the publisher decides to send a particular
> > + transaction downstream. The delay does not take into
Dear Peter,
> 1.
> +-- fail - utilizing streaming = parallel with time-delayed
> replication is not supported
> +CREATE SUBSCRIPTION regress_testsub CONNECTION
> 'dbname=regress_doesnotexist' PUBLICATION testpub WITH (connect =
> false, streaming = parallel, min_send_delay = 123);
>
>
Dear Peter,
Thank you for reviewing! PSA new version.
> 1.
> If the subscription sets min_send_delay parameter, an apply worker passes the
> value to the publisher as an output plugin option. And then, the walsender
> will
> delay the transaction sending for given milliseconds.
>
> ~
>
> 1a.
On Tue, Feb 21, 2023 at 3:31 AM Peter Smith wrote:
>
>
> 2.
> The combination of parallel streaming mode and min_send_delay is not allowed.
> This is because in parallel streaming mode, we start applying the transaction
> stream as soon as the first change arrives without knowing the
Here are some review comments for the v3-0001 test code.
==
src/test/regress/sql/subscription.sql
1.
+-- fail - utilizing streaming = parallel with time-delayed
replication is not supported
+CREATE SUBSCRIPTION regress_testsub CONNECTION
'dbname=regress_doesnotexist' PUBLICATION testpub WITH
Here are some review comments for patch v3-0001.
(I haven't looked at the test code yet)
==
Commit Message
1.
If the subscription sets min_send_delay parameter, an apply worker passes the
value to the publisher as an output plugin option. And then, the walsender will
delay the transaction
Dear Amit,
Thank you for reviewing! PSA new version.
> 1.
> +
> + The minimum delay for publisher sends data, in milliseconds
> +
> +
>
> It would probably be better to write it as "The minimum delay, in
> milliseconds, by the publisher to send changes"
Fixed.
> 2. The
On Fri, Feb 17, 2023 at 12:14 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Thank you for replying! This direction seems OK, so I started to revise the
> patch.
> PSA new version.
>
Few comments:
=
1.
+
+ The minimum delay for publisher sends data, in milliseconds
+
+
Dear Andres,
Thank you for giving comments! I understood that you have agreed the approach
that publisher delays to send data.
> > I'm not sure why output plugin is involved in the delay mechanism.
>
> +many
>
> The output plugin absolutely never should be involved in something like
> this. It
Dear Amit,
> > > > Perhaps what I understand
> > > > correctly is that we could delay right before only sending commit
> > > > records in this case. If we delay at publisher end, all changes will
> > > > be sent at once if !streaming, and otherwise, all changes in a
> > > > transaction will be
Dear Horiguchi-san,
Thank you for replying! This direction seems OK, so I started to revise the
patch.
PSA new version.
> > > As Amit-K mentioned, we may need to change the name of the option in
> > > this version, since the delay mechanism in this version causes a delay
> > > in sending from
Hi,
On 2023-02-16 14:21:01 +0900, Kyotaro Horiguchi wrote:
> I'm not sure why output plugin is involved in the delay mechanism.
+many
The output plugin absolutely never should be involved in something like
this. It was a grave mistake that OutputPluginUpdateProgress() calls were
added to the
On Thu, Feb 16, 2023 at 2:25 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 16 Feb 2023 06:20:23 +, "Hayato Kuroda (Fujitsu)"
> wrote in
> > Dear Horiguchi-san,
> >
> > Thank you for responding! Before modifying patches, I want to confirm
> > something
> > you said.
> >
> > > As Amit-K mentioned,
At Thu, 16 Feb 2023 06:20:23 +, "Hayato Kuroda (Fujitsu)"
wrote in
> Dear Horiguchi-san,
>
> Thank you for responding! Before modifying patches, I want to confirm
> something
> you said.
>
> > As Amit-K mentioned, we may need to change the name of the option in
> > this version, since
Dear Horiguchi-san,
Thank you for responding! Before modifying patches, I want to confirm something
you said.
> As Amit-K mentioned, we may need to change the name of the option in
> this version, since the delay mechanism in this version causes a delay
> in sending from publisher than delaying
At Wed, 15 Feb 2023 11:29:18 +, "Hayato Kuroda (Fujitsu)"
wrote in
> Dear Andres and other hackers,
>
> > OTOH, if we want to implement the functionality on publisher-side,
> > I think we need to first consider the interface.
> > We can think of two options (a) Have it as a subscription
Dear Andres and other hackers,
> OTOH, if we want to implement the functionality on publisher-side,
> I think we need to first consider the interface.
> We can think of two options (a) Have it as a subscription parameter as the
> patch
> has now and
> then pass it as an option to the publisher
Hi, Andres-san
On Tuesday, February 14, 2023 1:47 AM Andres Freund wrote:
> On 2023-02-11 05:44:47 +, Takamichi Osumi (Fujitsu) wrote:
> > On Saturday, February 11, 2023 11:10 AM Andres Freund
> wrote:
> > > Has there been any discussion about whether this is actually best
> > >
At Mon, 13 Feb 2023 15:51:25 +0530, Amit Kapila wrote
in
> I think we can introduce a new variable as last_feedback_time in the
> LogicalRepWorker structure and probably for the last_received, we can
> last_lsn in MyLogicalRepWorker as that seems to be updated correctly.
> I think it would be
Hi,
On 2023-02-11 05:44:47 +, Takamichi Osumi (Fujitsu) wrote:
> On Saturday, February 11, 2023 11:10 AM Andres Freund
> wrote:
> > Has there been any discussion about whether this is actually best
> > implemented on the client side? You could alternatively implement it on the
> > sender.
>
On Fri, Feb 10, 2023 at 4:56 PM Takamichi Osumi (Fujitsu)
wrote:
>
> On Friday, February 10, 2023 2:05 PM Friday, February 10, 2023 2:05 PM wrote:
> > On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila
> > wrote:
>
> In the previous patch, we couldn't solve the
> timeout of the publisher, when we
Here are my review comments for the v34 patch.
==
src/backend/replication/logical/worker.c
+/* The last time we send a feedback message */
+static TimestampTz send_time = 0;
+
IMO this is a bad variable name. When this variable was changed to be
global it ought to have been renamed.
The
Hi, Horiguchi-san
On Monday, February 13, 2023 10:26 AM Kyotaro Horiguchi
wrote:
> At Fri, 10 Feb 2023 10:34:49 +0530, Amit Kapila
> wrote in
> > On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila
> wrote:
> > >
> > > On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi
> > > wrote:
> > > > We have
At Fri, 10 Feb 2023 10:34:49 +0530, Amit Kapila wrote
in
> On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila wrote:
> >
> > On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi
> > wrote:
> > > We have suffered this kind of feedback silence many times. Thus I
> > > don't want to rely on luck here. I
Hi
On Saturday, February 11, 2023 11:10 AM Andres Freund
wrote:
> On 2023-02-10 11:26:21 +, Takamichi Osumi (Fujitsu) wrote:
> > Subject: [PATCH v34] Time-delayed logical replication subscriber
> >
> > Similar to physical replication, a time-delayed copy of the data for
> > logical
Hi,
On 2023-02-10 11:26:21 +, Takamichi Osumi (Fujitsu) wrote:
> Subject: [PATCH v34] Time-delayed logical replication subscriber
>
> Similar to physical replication, a time-delayed copy of the data for
> logical replication is useful for some scenarios (particularly to fix
> errors that
Hi,
On Friday, February 10, 2023 2:05 PM Friday, February 10, 2023 2:05 PM wrote:
> On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila
> wrote:
> >
> > On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila
> > > wrote in
> > > > On
On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila wrote:
>
> On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila
> > wrote in
> > > On Thu, Feb 9, 2023 at 10:45 AM Kyotaro Horiguchi
> > > wrote:
> > > >
> > > > At Wed, 8 Feb 2023
On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila
> wrote in
> > On Thu, Feb 9, 2023 at 10:45 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Wed, 8 Feb 2023 09:03:03 +, "Hayato Kuroda (Fujitsu)"
> > > wrote in
> > > > Thank you
Mmm. A part of the previous mail have gone anywhere for a uncertain
reason and placed by a mysterious blank lines...
At Fri, 10 Feb 2023 09:57:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila
> wrote in
> > On Thu, Feb 9, 2023 at 10:45 AM Kyotaro
At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila wrote
in
> On Thu, Feb 9, 2023 at 10:45 AM Kyotaro Horiguchi
> wrote:
> >
> > At Wed, 8 Feb 2023 09:03:03 +, "Hayato Kuroda (Fujitsu)"
> > wrote in
> > > Thank you for reviewing! PSA new version.
> >
> > + if (statusinterval_ms
At Thu, 9 Feb 2023 13:26:19 +0530, Amit Kapila wrote
in
amit.kapila16> On Thu, Feb 9, 2023 at 12:17 AM Peter Smith
wrote:
> > I understand in theory, your code is more efficient, but in practice,
> > I think the overhead of a single variable assignment every loop
> > iteration (which is doing
> The comment adjustment suggested by Peter-san above
> was also included in this v33.
> Please have a look at the attached patch.
Patch v33 LGTM.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
Hi,
On Thursday, February 9, 2023 4:56 PM Amit Kapila
wrote:
> On Thu, Feb 9, 2023 at 12:17 AM Peter Smith
> wrote:
> >
> > On Wed, Feb 8, 2023 at 8:03 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > ...
> > > > ==
> > > >
> > > > src/backend/replication/logical/worker.c
> > > >
> > > >
On Thu, Feb 9, 2023 at 10:45 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 8 Feb 2023 09:03:03 +, "Hayato Kuroda (Fujitsu)"
> wrote in
> > Thank you for reviewing! PSA new version.
>
> + if (statusinterval_ms > 0 && diffms > statusinterval_ms)
>
> The next expected feedback time is
On Thu, Feb 9, 2023 at 12:17 AM Peter Smith wrote:
>
> On Wed, Feb 8, 2023 at 8:03 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> ...
> > > ==
> > >
> > > src/backend/replication/logical/worker.c
> > >
> > > 2. maybe_apply_delay
> > >
> > > + if (wal_receiver_status_interval > 0 &&
> > > + diffms
At Wed, 8 Feb 2023 09:03:03 +, "Hayato Kuroda (Fujitsu)"
wrote in
> Thank you for reviewing! PSA new version.
+ if (statusinterval_ms > 0 && diffms > statusinterval_ms)
The next expected feedback time is measured from the last status
report. Thus, it seems to me this may
On Wed, Feb 8, 2023 at 8:03 PM Hayato Kuroda (Fujitsu)
wrote:
>
...
> > ==
> >
> > src/backend/replication/logical/worker.c
> >
> > 2. maybe_apply_delay
> >
> > + if (wal_receiver_status_interval > 0 &&
> > + diffms > wal_receiver_status_interval * 1000L)
> > + {
> > + WaitLatch(MyLatch,
> >
Dear Peter,
Thank you for reviewing! PSA new version.
> ==
> doc/src/sgml/glossary.sgml
>
> 1.
> +
> + Replication setup that applies time-delayed copy of the data.
> +
>
> That sentence seemed a bit strange to me.
>
> SUGGESTION
> Replication setup that delays the
Here are my review comments for v31-0001
==
doc/src/sgml/glossary.sgml
1.
+
+ Replication setup that applies time-delayed copy of the data.
+
That sentence seemed a bit strange to me.
SUGGESTION
Replication setup that delays the application of changes by a
specified minimum
Hi, Horiguchi-san
Thanks for your review !
On Tuesday, February 7, 2023 1:43 PM From: Kyotaro Horiguchi
wrote:
> At Mon, 6 Feb 2023 13:10:01 +, "Takamichi Osumi (Fujitsu)"
> wrote in
> subscriptioncmds.c
>
> + if (opts.streaming ==
>
Hi,
On Tuesday, February 7, 2023 2:26 PM Amit Kapila
wrote:
> On Tue, Feb 7, 2023 at 10:13 AM Kyotaro Horiguchi
> wrote:
> >
> > At Mon, 6 Feb 2023 13:10:01 +, "Takamichi Osumi (Fujitsu)"
> > wrote in
> > > The attached patch v29 has included your changes.
> >
> > catalogs.sgml
> >
> > +
Hi,
On Tuesday, February 7, 2023 6:56 PM Amit Kapila
wrote:
> On Tue, Feb 7, 2023 at 8:22 AM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Thank you for reviewing! PSA new version.
> >
>
> Few comments:
> =
Thanks for your comments !
> 1.
> @@ -74,6 +74,8 @@
On Tue, Feb 7, 2023 at 8:22 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Thank you for reviewing! PSA new version.
>
Few comments:
=
1.
@@ -74,6 +74,8 @@ CATALOG(pg_subscription,6100,SubscriptionRelationId)
BKI_SHARED_RELATION BKI_ROW
Oid subowner BKI_LOOKUP(pg_authid); /* Owner of the
On Tue, Feb 7, 2023 at 10:42 AM Peter Smith wrote:
>
> On Tue, Feb 7, 2023 at 4:02 PM Amit Kapila wrote:
> >
> > On Tue, Feb 7, 2023 at 10:07 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Tue, 7 Feb 2023 09:10:01 +0530, Amit Kapila
> > > wrote in
> > > > On Tue, Feb 7, 2023 at 6:03 AM Peter
1 - 100 of 338 matches
Mail list logo
