Hayato Kuroda kindly rebased the patch.
v2-0001-WIP-track-wal-segments.patch
Description: application/mbox
On Fri, 27 Dec 2024 at 09:41, vignesh C wrote:
>
> On Wed, 25 Dec 2024 at 13:55, Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Marc,
> >
> > > Thanks again for this new patch.
> > >
> > > Unfortunately it does not compile (17.2 source):
> >
> > Right, because of the reason I posted [1].
> >
> > I
> Right, because of the reason I posted [1].
>
> I updated the patch which did the same approach. It could pass my CI.
> Could you please apply on 17.2 and test it?
>
> [1]:
> https://www.postgresql.org/message-id/OSCPR01MB14966B646506E0C9B81B3A4CFF5022%40OSCPR01MB14966.jpnprd01.prod.outlook.com
On Wed, 25 Dec 2024 at 13:55, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Marc,
>
> > Thanks again for this new patch.
> >
> > Unfortunately it does not compile (17.2 source):
>
> Right, because of the reason I posted [1].
>
> I updated the patch which did the same approach. It could pass my CI.
Let'
Dear Marc,
> Thanks again for this new patch.
>
> Unfortunately it does not compile (17.2 source):
Right, because of the reason I posted [1].
I updated the patch which did the same approach. It could pass my CI.
Could you please apply on 17.2 and test it?
[1]:
https://www.postgresql.org/messa
> I came up with an alternate approach. In this approach we keep track
> of wal segment the transaction is part of. This helps to iterate
> through only required files during clean up.
>
> On my machine, I am running the testcase provided by you in [1]. It is
> generating ~1.9 million spill files.
Dear Shlok,
>
> Thanks for sharing the analysis.
>
> I tested the patch on my machine as well and it has worse performance
> for me as well.
> I came up with an alternate approach. In this approach we keep track
> of wal segment the transaction is part of. This helps to iterate
> through only re
Dear Marc,
Thanks for the reply!
> Thanks for your suggestions that were both already tested. In our (real) case
> (a
> single transaction with 12 millions sub-transactions):
>
> 1) setting the subscription as streaming, just delay a bit the spill file
> surge. It does
> not prevent the creati
> Can you enable the parameter "streaming" to on on your system [1]? It allows
> to
> stream the in-progress transactions to the subscriber side. I feel this can
> avoid
> the case that there are many .spill files on the publisher side.
> Another approach is to tune the logical_decoding_work_mem
Dear Marc,
> For some unknown reason (probably a very big transaction at the source), we
> experienced a logical decoding breakdown,
...
> When those timeout occurred, the sender was still busy deleting files from
> data/pg_replslot/bdcpb21_sene, accumulating more than 6 millions small
> ".spill"
On Thu, 12 Dec 2024 at 19:20, RECHTÉ Marc wrote:
>
> Hi,
>
> Thanks for sharing the test case.
> Unfortunately I donot have a powerful machine which would generate
> such large number of spill files. But I created a patch as per your
> suggestion in point(2) in thread [1]. Can you test with this p
Hi,
Thanks for sharing the test case.
Unfortunately I donot have a powerful machine which would generate
such large number of spill files. But I created a patch as per your
suggestion in point(2) in thread [1]. Can you test with this patch on
your machine?
With this patch instead of calling unlin
On Wed, 11 Dec 2024 at 14:29, RECHTÉ Marc wrote:
>
> This how to reproduce the problem.
>
> Session 1:
>
> psql -c "CREATE TABLE test (i int)" -c "INSERT INTO test SELECT
> generate_series(1, 2_000_000)"
>
> Session 2:
>
> pg_recvlogical -d postgres --slot=test --create-slot
> pg_recvlogical -d
This how to reproduce the problem.
Session 1:
psql -c "CREATE TABLE test (i int)" -c "INSERT INTO test SELECT
generate_series(1, 2_000_000)"
Session 2:
pg_recvlogical -d postgres --slot=test --create-slot
pg_recvlogical -d postgres --slot=test --start -f -
Session 3:
cd data/pg_repslots
w
On Wed, 6 Nov 2024 at 13:07, RECHTÉ Marc wrote:
>
> Hello,
>
> For some unknown reason (probably a very big transaction at the source), we
> experienced a logical decoding breakdown,
> due to a timeout from the subscriber side (either wal_receiver_timeout or
> connexion drop by network equipment
On Wed, Nov 6, 2024 at 1:07 PM RECHTÉ Marc wrote:
>
> Hello,
>
> For some unknown reason (probably a very big transaction at the source), we
> experienced a logical decoding breakdown,
> due to a timeout from the subscriber side (either wal_receiver_timeout or
> connexion drop by network equipme
Hello,
For some unknown reason (probably a very big transaction at the source), we
experienced a logical decoding breakdown,
due to a timeout from the subscriber side (either wal_receiver_timeout or
connexion drop by network equipment due to inactivity).
The problem is, that due to that fail
On Thu, Mar 2, 2023 at 4:19 AM Gregory Stark (as CFM)
wrote:
> On Wed, 8 Feb 2023 at 15:04, Andres Freund wrote:
> >
> > Attached is a current, quite rough, prototype. It addresses some of the
> > points
> > raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> >
On Wed, 8 Feb 2023 at 15:04, Andres Freund wrote:
>
> Attached is a current, quite rough, prototype. It addresses some of the points
> raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> the file-ending to .txt to avoid hijacking the CF entry.
It looks like this patch h
On Thu, Feb 9, 2023 at 11:21 AM Amit Kapila wrote:
>
>
> How about renaming ProcessPendingWrites to WaitToSendPendingWrites or
> WalSndWaitToSendPendingWrites?
>
How about renaming WalSndUpdateProgress() to
WalSndUpdateProgressAndSendKeepAlive() or
WalSndUpdateProgressAndKeepAlive()?
One thing t
On Thu, Feb 9, 2023 at 1:33 AM Andres Freund wrote:
>
> Hacking on a rough prototype how I think this should rather look, I had a few
> questions / remarks:
>
> - We probably need to call UpdateProgress from a bunch of places in decode.c
> as well? Indicating that we're lagging by a lot, just be
Hi,
On 2023-02-08 10:30:37 -0800, Andres Freund wrote:
> On 2023-02-08 10:18:41 -0800, Andres Freund wrote:
> > I don't think the syncrep logic in WalSndUpdateProgress really works as-is -
> > consider what happens if e.g. the origin filter filters out entire
> > transactions. We'll afaics never g
Hi,
On 2023-02-08 10:18:41 -0800, Andres Freund wrote:
> I don't think the syncrep logic in WalSndUpdateProgress really works as-is -
> consider what happens if e.g. the origin filter filters out entire
> transactions. We'll afaics never get to WalSndUpdateProgress(). In some cases
> we'll be luck
Hi,
On 2023-02-08 13:36:02 +0530, Amit Kapila wrote:
> On Wed, Feb 8, 2023 at 10:57 AM Andres Freund wrote:
> >
> > On 2023-02-03 10:13:54 +0530, Amit Kapila wrote:
> > > I am planning to push this to HEAD sometime next week (by Wednesday).
> > > To backpatch this, we need to fix it in some non-s
On Wed, Feb 8, 2023 at 10:57 AM Andres Freund wrote:
>
> On 2023-02-03 10:13:54 +0530, Amit Kapila wrote:
> > I am planning to push this to HEAD sometime next week (by Wednesday).
> > To backpatch this, we need to fix it in some non-standard way, like
> > without introducing a callback which I am
Hi,
On 2023-02-03 10:13:54 +0530, Amit Kapila wrote:
> I am planning to push this to HEAD sometime next week (by Wednesday).
> To backpatch this, we need to fix it in some non-standard way, like
> without introducing a callback which I am not sure is a good idea. If
> some other committers vote to
On Wed, Feb 1, 2023 at 10:04 AM Amit Kapila wrote:
>
> On Tue, Jan 31, 2023 at 8:24 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jan 31, 2023 at 5:12 PM Amit Kapila wrote:
> > >
> > > On Tue, Jan 31, 2023 at 5:03 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Tue, Jan 31, 2023 at 4:58 PM Amit
On Tue, Jan 31, 2023 at 8:24 PM Ashutosh Bapat
wrote:
>
> On Tue, Jan 31, 2023 at 5:12 PM Amit Kapila wrote:
> >
> > On Tue, Jan 31, 2023 at 5:03 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Tue, Jan 31, 2023 at 4:58 PM Amit Kapila
> > > wrote:
> > >
> > > > Thanks, the patch looks good to me.
On Wed, Feb 1, 2023 at 4:43 AM Peter Smith wrote:
>
> Here are my review comments for v13-1.
>
> ==
> Commit message
>
> 1.
> The DDLs like Refresh Materialized views that generate lots of temporary
> data due to rewrite rules may not be processed by output plugins (for
> example pgoutput)
Here are my review comments for v13-1.
==
Commit message
1.
The DDLs like Refresh Materialized views that generate lots of temporary
data due to rewrite rules may not be processed by output plugins (for
example pgoutput). So, we won't send keep-alive messages for a long time
while process
On Tue, Jan 31, 2023 at 5:12 PM Amit Kapila wrote:
>
> On Tue, Jan 31, 2023 at 5:03 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jan 31, 2023 at 4:58 PM Amit Kapila wrote:
> >
> > > Thanks, the patch looks good to me. I have slightly adjusted one of
> > > the comments and ran pgindent. See attache
On Tue, Jan 31, 2023 at 5:03 PM Ashutosh Bapat
wrote:
>
> On Tue, Jan 31, 2023 at 4:58 PM Amit Kapila wrote:
>
> > Thanks, the patch looks good to me. I have slightly adjusted one of
> > the comments and ran pgindent. See attached. As mentioned in the
> > commit message, we shouldn't backpatch th
On Tue, Jan 31, 2023 at 4:58 PM Amit Kapila wrote:
> Thanks, the patch looks good to me. I have slightly adjusted one of
> the comments and ran pgindent. See attached. As mentioned in the
> commit message, we shouldn't backpatch this as this requires a new
> callback and moreover, users can incre
justed one of
the comments and ran pgindent. See attached. As mentioned in the
commit message, we shouldn't backpatch this as this requires a new
callback and moreover, users can increase the wal_sender_timeout and
wal_receiver_timeout to avoid this problem. What do you think?
--
With
ion of the counter
"changes_count" outside the while-loop and did not use the keyword "static".
Attach the new patch.
Regards,
Wang Wei
v11-0001-Fix-the-logical-replication-timeout-during-proce.patch
Description: v11-0001-Fix-the-logical-replication-timeout-during-proce.patch
ction update_progress_txn_cb_wrapper to
be consistent with the nearby *_cb_wrapper functions.
Attach the new patch.
Regards,
Wang Wei
v10-0001-Fix-the-logical-replication-timeout-during-proce.patch
Description: v10-0001-Fix-the-logical-replication-timeout-during-proce.patch
On Mon, Jan 30, 2023 at 10:36 AM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Jan 30, 2023 11:37 AM Shi, Yu/侍 雨 wrote:
> > On Sun, Jan 29, 2023 3:41 PM wangw.f...@fujitsu.com
> > wrote:
>
> Yes, I think you are right.
> Fixed this problem.
>
+ /*
+ * Trying to send keepalive message after every ch
utputPluginUpdateProgress(), otherwise
> OutputPluginUpdateProgress() will always be called after 100 changes.
Yes, I think you are right.
Fixed this problem.
Attach the new patch.
Regards,
Wang Wei
v9-0001-Fix-the-logical-replication-timeout-during-proces.patch
Description: v9-0001-Fix-the-logical-replication-timeout-during-proces.patch
On Sun, Jan 29, 2023 3:41 PM wangw.f...@fujitsu.com
wrote:
>
> I tested a mix transaction of transactional and non-transactional messages on
> the current HEAD and reproduced the timeout problem. I think this result is
> OK.
> Because when decoding a transaction, non-transactional changes are p
roduced the timeout problem. I think this result is OK.
Because when decoding a transaction, non-transactional changes are processed
directly and the function WalSndKeepaliveIfNecessary is called, while
transactional changes are cached and processed after decoding. After decoding,
only transactional changes will be proc
On Fri, Jan 27, 2023 at 5:18 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, January 25, 2023 7:26 PM Amit Kapila
> >
> > On Tue, Jan 24, 2023 at 8:15 AM wangw.f...@fujitsu.com
> > wrote:
> > >
> > > Attach the new patch.
> > >
> >
> > I think the patch missed to handle the case of non-transa
On Wednesday, January 25, 2023 7:26 PM Amit Kapila
>
> On Tue, Jan 24, 2023 at 8:15 AM wangw.f...@fujitsu.com
> wrote:
> >
> > Attach the new patch.
> >
>
> I think the patch missed to handle the case of non-transactional messages
> which
> was previously getting handled. I have tried to addre
e comments for the callback.
Additionally, I think we should have a test case to show we don't time
out because of not processing non-transactional messages. See
pgoutput_message for cases where it doesn't process the message.
--
With Regards,
Amit Kapila.
v7-0001-Fix-the-logical-re
On Tue, Jan 24, 2023 at 1:45 PM wangw.f...@fujitsu.com
wrote:
>
> On Tues, Jan 24, 2023 at 8:28 AM Peter Smith wrote:
> > Hi Hou-san, Here are my review comments for v5-0001.
>
> Thanks for your comments.
...
>
> Changed as suggested.
>
> Attach the new patch.
Thanks! Patch v6 LGTM.
--
Kind
there is no noticeable overhead if
> keepalive is only
> * sent after every ~100 changes.
> */
> #define CHANGES_THRESHOLD 100
> if (++changes_count >= CHANGES_THRESHOLD)
> {
> rb->update_progress_txn(rb, txn, c
Hi Hou-san, Here are my review comments for v5-0001.
==
src/backend/replication/logical/reorderbuffer.c
1.
@@ -2446,6 +2452,23 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
ReorderBufferTXN *txn,
elog(ERROR, "tuplecid value in changequeue");
break;
}
+
+ /*
+ * Sending keepalive message
_THRESHOLD 100
> +
>
> IMO these can be relocated to be declared/defined inside the "while"
> loop -- i.e. closer to where they are being used.
Moved into the while loop.
Attach the new version patch which addressed above comments.
Also attach a simple script which use "refresh matview" to reproduce
this timeout problem just in case some one want to try to reproduce this.
Best regards,
Hou zj
test.sh
Description: test.sh
v5-0001-Fix-the-logical-replication-timeout-during-proces.patch
Description: v5-0001-Fix-the-logical-replication-timeout-during-proces.patch
On Mon, Jan 23, 2023 at 6:21 AM Peter Smith wrote:
>
> 1.
>
> It makes no real difference, but I was wondering about:
> "update txn progress" versus "update progress txn"
>
Yeah, I think we can go either way but I still prefer "update progress
txn" as that is more closer to LogicalOutputPluginWri
Here are my review comments for patch v4-0001
==
General
1.
It makes no real difference, but I was wondering about:
"update txn progress" versus "update progress txn"
I thought that the first way sounds more natural. YMMV.
If you change this then there is impact for the typedef, function
n
On Fri, Jan 20, 2023 at 10:10 AM Peter Smith wrote:
> Here are some review comments for patch v3-0001.
Thanks for your comments.
> ==
> Commit message
>
> 1.
> The problem is when there is a DDL in a transaction that generates lots of
> temporary data due to rewrite rules, these temporary d
On Fri, Jan 20, 2023 at 12:35 PM Amit Kapila wrote:
> On Fri, Jan 20, 2023 at 7:40 AM Peter Smith wrote:
> >
> > Here are some review comments for patch v3-0001.
> >
> > ==
> > src/backend/replication/logical/logical.c
> >
> > 3. forward declaration
> >
> > +/* update progress callback */
> >
well. Anybody
> else has an opinion on this?
I think 'update_progress_txn' might be better. Because I think this name seems
to make it easier to know that this callback is used to update process when
processing txn. So, I rename it to 'update_progress_txn'.
I have addressed all the comments and here is the new version patch.
Regards,
Wang Wei
v4-0001-Fix-the-logical-replication-timeout-during-proces.patch
Description: v4-0001-Fix-the-logical-replication-timeout-during-proces.patch
On Fri, Jan 20, 2023 at 3:35 PM Amit Kapila wrote:
>
> On Fri, Jan 20, 2023 at 7:40 AM Peter Smith wrote:
> >
> > Here are some review comments for patch v3-0001.
> >
> > ==
> > src/backend/replication/logical/logical.c
> >
> > 3. forward declaration
> >
> > +/* update progress callback */
>
On Fri, Jan 20, 2023 at 7:40 AM Peter Smith wrote:
>
> Here are some review comments for patch v3-0001.
>
> ==
> src/backend/replication/logical/logical.c
>
> 3. forward declaration
>
> +/* update progress callback */
> +static void update_progress_cb_wrapper(ReorderBuffer *cache,
> +Reord
Here are some review comments for patch v3-0001.
==
Commit message
1.
The problem is when there is a DDL in a transaction that generates lots of
temporary data due to rewrite rules, these temporary data will not be processed
by the pgoutput - plugin. Therefore, the previous fix (f95d53e) for
On Thu, Jan 19, 2023 at 4:13 PM Ashutosh Bapat
wrote:
>
> On Wed, Jan 18, 2023 at 6:00 PM Amit Kapila wrote:
>
> > + */
> > + ReorderBufferUpdateProgressCB update_progress;
> >
> > Are you suggesting changing the name of the above variable? If so, how
> > about apply_progress, progress, or update
On Wed, Jan 18, 2023 at 6:00 PM Amit Kapila wrote:
> + */
> + ReorderBufferUpdateProgressCB update_progress;
>
> Are you suggesting changing the name of the above variable? If so, how
> about apply_progress, progress, or updateprogress? If you don't like
> any of these then feel free to suggest s
On Wed, Jan 18, 2023 at 5:37 PM Ashutosh Bapat
wrote:
>
> On Wed, Jan 18, 2023 at 1:49 PM wangw.f...@fujitsu.com
> wrote:
> >
> > On Wed, Jan 18, 2023 at 13:29 PM Amit Kapila
> > wrote:
> > > On Tue, Jan 17, 2023 at 6:41 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Tue, Jan 17, 2023 at 3:
On Wed, Jan 18, 2023 at 1:49 PM wangw.f...@fujitsu.com
wrote:
>
> On Wed, Jan 18, 2023 at 13:29 PM Amit Kapila wrote:
> > On Tue, Jan 17, 2023 at 6:41 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Tue, Jan 17, 2023 at 3:34 PM Amit Kapila
> > > wrote:
> > >
> > > > >
> > > > > I am a bit worried
mprove the patch based on this approach.
And I tried to add some comments for this new callback to distinguish it from
ctx->update_progress.
Attach the new patch.
Regards,
Wang Wei
v3-0001-Fix-the-logical-replication-timeout-during-proces.patch
Description: v3-0001-Fix-the-logical-replication-timeout-during-proces.patch
On Tue, Jan 17, 2023 at 6:41 PM Ashutosh Bapat
wrote:
>
> On Tue, Jan 17, 2023 at 3:34 PM Amit Kapila wrote:
>
> > >
> > > I am a bit worried about the indirections that the wrappers and hooks
> > > create. Output plugins call OutputPluginUpdateProgress() in callbacks
> > > but I don't see why R
On Tue, Jan 17, 2023 at 3:34 PM Amit Kapila wrote:
> >
> > I am a bit worried about the indirections that the wrappers and hooks
> > create. Output plugins call OutputPluginUpdateProgress() in callbacks
> > but I don't see why ReorderBufferProcessTXN() needs a callback to
> > call OutputPluginUp
On Mon, Jan 16, 2023 at 10:06 PM Ashutosh Bapat
wrote:
>
> On Wed, Jan 11, 2023 at 4:11 PM wangw.f...@fujitsu.com
> wrote:
> >
> > On Mon, Jan 9, 2023 at 13:04 PM Amit Kapila wrote:
> > >
> >
> > Thanks for your comments.
> >
> > > One more thing, I think it would be better to expose a new callb
On Wed, Jan 11, 2023 at 4:11 PM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Jan 9, 2023 at 13:04 PM Amit Kapila wrote:
> >
>
> Thanks for your comments.
>
> > One more thing, I think it would be better to expose a new callback
> > API via reorder buffer as suggested previously [2] similar to other
On Mon, Jan 9, 2023 at 4:08 PM wangw.f...@fujitsu.com
wrote:
>
> On Fri, Jan 6, 2023 at 15:06 PM Ashutosh Bapat
> wrote:
>
> I'm not sure if we need to add global variables or member variables for a
> cumulative count that is only used here. How would you feel if I add some
> comments when decla
of new function pgoutput_update_progress is
less than 0.1% of the total time. I think this result looks OK.
Attach the new patch.
Regards,
Wang Wei
v2-0001-Fix-the-logical-replication-timeout-during-proces.patch
Description: v2-0001-Fix-the-logical-replication-timeout-during-proces.patch
On Fri, Jan 6, 2023 at 15:06 PM Ashutosh Bapat
wrote:
> Hi Wang,
> Thanks for working on this. One of our customer faced a similar
> situation when running BDR with PostgreSQL.
>
> I tested your patch and it solves the problem.
>
> Please find some review comments below
Thanks for your testing
On Fri, Jan 6, 2023 at 12:35 PM Ashutosh Bapat
wrote:
>
> +
> +/*
> + * We don't want to try sending a keepalive message after processing each
> + * change as that can have overhead. Tests revealed that there is no
> + * noticeable overhead in doing it after continuously processing
Hi Wang,
Thanks for working on this. One of our customer faced a similar
situation when running BDR with PostgreSQL.
I tested your patch and it solves the problem.
Please find some review comments below
On Tue, Nov 8, 2022 at 8:34 AM wangw.f...@fujitsu.com
wrote:
>
>
> Attach the patch.
>
+/*
cal-replication-timeout-during-proces.patch
Description: v1-0001-Fix-the-logical-replication-timeout-during-proces.patch
Hello Wang,
I tested the draft patch in my lab for Postgres 14.4, the refresh of the
materialized view ran without generating the timeout on the worker.
Do you plan to propose this patch at the next commit fest.
Regards,
Fabrice
On Wed, Oct 19, 2022 at 10:15 AM wangw.f...@fujitsu.com <
wangw.f...
On Thurs, Oct 20, 2022 at 13:47 PM Fabrice Chapuis
wrote:
> Yes the refresh of MV is on the Publisher Side.
> Thanks for your draft patch, I'll try it
> I'll back to you as soonas possible
Thanks a lot.
> One question: why the refresh of the MV is a DDL not a DML?
Since in the source, the type
Yes the refresh of MV is on the Publisher Side.
Thanks for your draft patch, I'll try it
I'll back to you as soonas possible
One question: why the refresh of the MV is a DDL not a DML?
Regards
Fabrice
On Wed, 19 Oct 2022, 10:15 wangw.f...@fujitsu.com
wrote:
> On Tue, Oct 18, 2022 at 22:35 PM
On Tue, Oct 18, 2022 at 22:35 PM Fabrice Chapuis
wrote:
> Hello Amit,
>
> In version 14.4 the timeout problem for logical replication happens again
> despite
> the patch provided for this issue in this version. When bulky materialized
> views
> are reloaded it broke logical replication. It is p
Hello Amit,
In version 14.4 the timeout problem for logical replication happens again
despite the patch provided for this issue in this version. When bulky
materialized views are reloaded it broke logical replication. It is
possible to solve this problem by using your new "streaming" option.
Have
On Mon, May 9, 2022 at 2:17 PM Masahiko Sawada wrote:
>
> The patches look good to me too.
>
Pushed.
--
With Regards,
Amit Kapila.
On Mon, May 9, 2022 at 11:23 AM Amit Kapila wrote:
> On Mon, May 9, 2022 at 7:01 PM Euler Taveira wrote:
> >
> > On Mon, May 9, 2022, at 3:47 AM, Amit Kapila wrote:
> >
> > Thanks. The patch LGTM. I'll push and back-patch this after the
> > current minor release is done unless there are more comm
On Mon, May 9, 2022 at 7:01 PM Euler Taveira wrote:
>
> On Mon, May 9, 2022, at 3:47 AM, Amit Kapila wrote:
>
> Thanks. The patch LGTM. I'll push and back-patch this after the
> current minor release is done unless there are more comments related
> to this work.
>
> Looks sane to me. (I only teste
On Mon, May 9, 2022, at 3:47 AM, Amit Kapila wrote:
> Thanks. The patch LGTM. I'll push and back-patch this after the
> current minor release is done unless there are more comments related
> to this work.
Looks sane to me. (I only tested the HEAD version)
+ boolend_xact = ctx->end_xact;
On Mon, May 9, 2022 at 3:47 PM Amit Kapila wrote:
>
> On Fri, May 6, 2022 at 12:42 PM wangw.f...@fujitsu.com
> wrote:
> >
> > On Fri, May 6, 2022 at 9:54 AM Masahiko Sawada
> > wrote:
> > > On Wed, May 4, 2022 at 7:18 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, May 2, 2022 at 8:07 AM
On Fri, May 6, 2022 at 12:42 PM wangw.f...@fujitsu.com
wrote:
>
> On Fri, May 6, 2022 at 9:54 AM Masahiko Sawada wrote:
> > On Wed, May 4, 2022 at 7:18 PM Amit Kapila wrote:
> > >
> > > On Mon, May 2, 2022 at 8:07 AM Masahiko Sawada
> > wrote:
> > > >
> > > > On Mon, May 2, 2022 at 11:32 AM Ami
ssion.
Move the CHANGES_THRESHOLD logic from function OutputPluginUpdateProgress to
new funcion update_replication_progress.
In addition, improve all patches formatting with pgindent.
Attach the patches.
Regards,
Wang wei
HEAD_v21-0001-Fix-the-logical-replication-timeout-during-large.patch
Descr
On Wed, May 4, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Mon, May 2, 2022 at 8:07 AM Masahiko Sawada wrote:
> >
> > On Mon, May 2, 2022 at 11:32 AM Amit Kapila wrote:
> > >
> > >
> > > So, shall we go back to the previous approach of using a separate
> > > function update_replication_progress?
>
Attached, please find the updated patch accordingly. Currently, I have
prepared it for HEAD, if you don't see any problem with this, we can
prepare the back-branch patches based on this.
--
With Regards,
Amit Kapila.
v20-0001-Fix-the-logical-replication-timeout-during-large.patch
Description: Binary data
On Mon, May 2, 2022 at 11:32 AM Amit Kapila wrote:
>
> On Mon, May 2, 2022 at 7:33 AM Masahiko Sawada wrote:
> > On Thu, Apr 28, 2022 at 7:01 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > Hi Sawada-san, Wang
> > >
> > > I was looking at the patch and noticed that we moved some logic from
> >
On Mon, May 2, 2022 at 7:33 AM Masahiko Sawada wrote:
> On Thu, Apr 28, 2022 at 7:01 PM houzj.f...@fujitsu.com
> wrote:
> >
> > Hi Sawada-san, Wang
> >
> > I was looking at the patch and noticed that we moved some logic from
> > update_replication_progress() to OutputPluginUpdateProgress() like
>
On Thu, Apr 28, 2022 at 7:01 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, April 20, 2022 3:21 PM Masahiko Sawada
> wrote:
> >
> > BTW the changes in
> > REL_14_v1-0001-Fix-the-logical-replication-timeout-during-large-.patch,
> > adding end_xact to Logical
fications.
Attach the back-branch patches for REL10~REL14.
(Also attach the patch for HEAD, I did not make any changes to this patch.)
BTW, I found Hou-san shared some points. After our discussion, I will update
the patches if required.
Regards,
Wang wei
HEAD_v19-0001-Fix-the-logical-repli
and changed a few comments in the attached. Let's use this to
prepare patches for back-branches.
--
With Regards,
Amit Kapila.
v19-0001-Fix-the-logical-replication-timeout-during-large.patch
Description: Binary data
On Wednesday, April 20, 2022 3:21 PM Masahiko Sawada
wrote:
>
> BTW the changes in
> REL_14_v1-0001-Fix-the-logical-replication-timeout-during-large-.patch,
> adding end_xact to LogicalDecodingContext, seems good to me and it
> might be better than the approach of v17 pa
L10~REL13.
(REL12 and REL11 patch are the same, so only post one patch for these two
branches.)
The patch for HEAD:
HEAD_v18-0001-Fix-the-logical-replication-timeout-during-large.patch
The patch for REL14:
REL14_v2-0001-Fix-the-logical-replication-timeout-during-large-.patch
The patch
On Thu, Apr 21, 2022 at 11:19 AM Amit Kapila wrote:
>
> On Wed, Apr 20, 2022 at 6:22 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 20, 2022 at 7:12 PM Amit Kapila wrote:
> > >
> >
> > > I think it would
> > > be then better to have it in the same place in HEAD as well?
> >
> > As far as I can se
On Wed, Apr 20, 2022 at 6:22 PM Masahiko Sawada wrote:
>
> On Wed, Apr 20, 2022 at 7:12 PM Amit Kapila wrote:
> >
>
> > I think it would
> > be then better to have it in the same place in HEAD as well?
>
> As far as I can see in the v17 patch, which is for HEAD, we don't add
> a variable to Logic
M Masahiko Sawada wrote:
> I'm concerned that this 4-byte padding at the end of the struct could
> depend on platforms (there might be no padding in 32-bit platforms?).
> It seems to me that it's better to put it after fast_forward where the
> new field should fall within the pa
On Wed, Apr 20, 2022 at 7:12 PM Amit Kapila wrote:
>
> On Wed, Apr 20, 2022 at 2:38 PM Amit Kapila wrote:
> >
> > On Wed, Apr 20, 2022 at 12:51 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com
> > > wrote:
> > > > ```
> > >
> > > I'm concerned t
On Wed, Apr 20, 2022 at 2:38 PM Amit Kapila wrote:
>
> On Wed, Apr 20, 2022 at 12:51 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com
> > wrote:
> > > ```
> >
> > I'm concerned that this 4-byte padding at the end of the struct could
> > depend on platf
On Wed, Apr 20, 2022 at 12:51 PM Masahiko Sawada wrote:
>
> On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com
> wrote:
> > ```
>
> I'm concerned that this 4-byte padding at the end of the struct could
> depend on platforms (there might be no padding in 32-bit platforms?).
>
Good point, but
; > [1] - https://www.postgresql.org/message-
> > id/2358496.1649168259%40sss.pgh.pa.us
> Thanks for your comments.
>
> I did some checks about adding the new variable in LogicalDecodingContext.
> I found that because of padding, if we add the new variable at the end of
> str
1] - https://www.postgresql.org/message-
> id/2358496.1649168259%40sss.pgh.pa.us
Thanks for your comments.
I did some checks about adding the new variable in LogicalDecodingContext.
I found that because of padding, if we add the new variable at the end of
structure, it dose not make the structur
s good to
> me.
Fix these.
Attach the new patch.
1. Fix wrong formatting. [suggestion by Sawada-San]
Regards,
Wang wei
v17-0001-Fix-the-logical-replication-timeout-during-large.patch
Description: v17-0001-Fix-the-logical-replication-timeout-during-large.patch
1 - 100 of 217 matches
Mail list logo
