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
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
On Tue, Jan 31, 2023 at 2:53 PM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Jan 30, 2023 at 17:50 PM I wrote:
> > Attach the new patch.
>
> When invoking the function ReorderBufferProcessTXN, the threshold-related
> counter "changes_count" may have some random value from the previous
> transaction's
On Mon, Jan 30, 2023 at 17:50 PM I wrote:
> Attach the new patch.
When invoking the function ReorderBufferProcessTXN, the threshold-related
counter "changes_count" may have some random value from the previous
transaction's processing. To fix this, I moved the definition of the counter
"changes_cou
On Mon, Jan 30, 2023 at 14:55 PM Amit Kapila wrote:
> 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
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
On Mon, Jan 30, 2023 11:37 AM Shi, Yu/侍 雨 wrote:
> 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.
> > Beca
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
On Fri, Jan 27, 2023 at 19:55 PM Amit Kapila wrote:
> 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
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
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 address
that in the attached. Is there a reason that shouldn't be handled?
Apar
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
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.
> ==
> src/backend/replication/logical/reorderbuffer.c
>
> 1.
> @@ -2446,6 +2452,23 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> ReorderBufferTXN *txn,
>
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
On Monday, January 23, 2023 8:51 AM Peter Smith wrote:
>
> Here are my review comments for patch v4-0001
> ==
> Commit message
>
> 2.
>
> 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
> pro
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 */
> >
On Thu, Jan 19, 2023 at 19:37 PM Amit Kapila wrote:
> 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
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
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 about the indirections that the wrappers and hooks
> > > > create. Output plugins call O
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
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
> reorder buffer APIs instead of directly using reorderbuffer API to
> invoke
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.
>
+/*
On Fri, Nov 4, 2022 at 18:13 PM Fabrice Chapuis wrote:
> 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.
Thanks for your con
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
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 Amit Kapila
> wrote:
> > > >
> > > >
> > > > So, shall we go back to the previous
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?
>
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?
>
> Ok, agreed.
>
Attached, please find the updated patch according
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 LogicalDecodingContext, seems good to me a
On Thur, Apr 28, 2022 at 6:26 PM Amit Kapila wrote:
> On Thu, Apr 21, 2022 at 3:21 PM wangw.f...@fujitsu.com
> wrote:
> >
>
> I think it is better to keep the new variable 'end_xact' at the end of
> the struct where it belongs for HEAD. In back branches, we can keep it
> at the place as you have
On Thu, Apr 21, 2022 at 3:21 PM wangw.f...@fujitsu.com
wrote:
>
I think it is better to keep the new variable 'end_xact' at the end of
the struct where it belongs for HEAD. In back branches, we can keep it
at the place as you have. Apart from that, I have made some cosmetic
changes and changed a
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 patch from plugin developer
On Wed, Apr 21, 2022 at 10:15 AM I wrote:
> The comments by Sawada-San sound reasonable to me.
> After doing check, I found that padding in HEAD is the same as in REL14.
> So I change the approach of patch for HEAD just like the patch for REL14.
Also attach the back-branch patches for REL10~REL13.
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
On Wed, Apr 20, 2022 at 6:13 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 that t
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
On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Apr 18, 2022 at 00:36 PM Amit Kapila wrote:
> > On Mon, Apr 18, 2022 at 9:29 AM Amit Kapila wrote:
> > >
> > > On Thu, Apr 14, 2022 at 5:52 PM Euler Taveira wrote:
> > > >
> > > > On Wed, Apr 13, 2022, at 7:45 AM, Amit K
On Mon, Apr 18, 2022 at 00:36 PM Amit Kapila wrote:
> On Mon, Apr 18, 2022 at 9:29 AM Amit Kapila wrote:
> >
> > On Thu, Apr 14, 2022 at 5:52 PM Euler Taveira wrote:
> > >
> > > On Wed, Apr 13, 2022, at 7:45 AM, Amit Kapila wrote:
> > >
> > > Sawada-San, Euler, do you have any opinion on this ap
On Mon, Apr 19, 2022 at 9:32 AM Masahiko Sawada wrote:
> Thank you for updating the patch.
Thanks for your comments.
> + * For a large transaction, if we don't send any change to the
> + downstream for a
> + * long time(exceeds the wal_receiver_timeout of standby) then it can
> timeout.
> + * Thi
On Mon, Apr 18, 2022 at 3:16 PM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Apr 18, 2022 at 00:35 PM Masahiko Sawada
> wrote:
> > On Mon, Apr 18, 2022 at 1:01 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 14, 2022 at 5:50 PM Masahiko Sawada
> > wrote:
> > > >
> > > > On Wed, Apr 13, 2022 at 7:45
1 - 100 of 215 matches
Mail list logo
