On Fri, Oct 16, 2020 at 2:00 AM Andres Freund wrote:
>
> On 2020-10-15 12:38:49 +0530, Amit Kapila wrote:
> > On Wed, Oct 14, 2020 at 4:51 PM Dilip Kumar wrote:
> > >
> > > On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Thanks for the tests. The latest patch lo
On 2020-10-15 12:38:49 +0530, Amit Kapila wrote:
> On Wed, Oct 14, 2020 at 4:51 PM Dilip Kumar wrote:
> >
> > On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila wrote:
> > >
> > >
> > > Thanks for the tests. The latest patch looks mostly good to me. I have
> > > made minor changes to the patch (a) chang
Hi Amit, Dilip,
I am glad to solve this problem, Thanks!
Best Regards,
--
Keisuke Kuroda
NTT Software Innovation Center
keisuke.kuroda.3...@gmail.com
On Thu, Oct 15, 2020 at 12:38 PM Amit Kapila wrote:
>
> On Wed, Oct 14, 2020 at 4:51 PM Dilip Kumar wrote:
> >
> > On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila wrote:
> > >
> > >
> > > Thanks for the tests. The latest patch looks mostly good to me. I have
> > > made minor changes to the patch (a)
On Wed, Oct 14, 2020 at 4:51 PM Dilip Kumar wrote:
>
> On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila wrote:
> >
> >
> > Thanks for the tests. The latest patch looks mostly good to me. I have
> > made minor changes to the patch (a) changed the order where the new
> > message is placed at one place t
On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila wrote:
>
> On Mon, Oct 12, 2020 at 3:23 PM Dilip Kumar wrote:
> >
> > On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila wrote:
> > >
> > >
> > > Okay, I think this makes sense. I think we should see the performance
> > > benefit for this case as well but mayb
On Mon, Oct 12, 2020 at 3:23 PM Dilip Kumar wrote:
>
> On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila wrote:
> >
> >
> > Okay, I think this makes sense. I think we should see the performance
> > benefit for this case as well but maybe to a bit lesser degree because
> > we will exclude some of the sub
On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila wrote:
>
> On Fri, Oct 9, 2020 at 2:19 PM Simon Riggs wrote:
> >
> > On Fri, 9 Oct 2020 at 04:10, Amit Kapila wrote:
> > >
> > > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> > > >
> > > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> > > >
On Fri, Oct 9, 2020 at 2:19 PM Simon Riggs wrote:
>
> On Fri, 9 Oct 2020 at 04:10, Amit Kapila wrote:
> >
> > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> > >
> > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> > >
> > > > > This script will wait 10 seconds after INSERT exits
> > > >
On Fri, 9 Oct 2020 at 04:10, Amit Kapila wrote:
>
> On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> >
> > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> >
> > > > This script will wait 10 seconds after INSERT exits
> > > > before executing TRUNCATE, please wait for it to run.
> >
> > Has
On Fri, Oct 9, 2020 at 10:29 AM Amit Kapila wrote:
>
> On Fri, Oct 9, 2020 at 10:06 AM Dilip Kumar wrote:
> >
> > On Fri, Oct 9, 2020 at 8:40 AM Amit Kapila wrote:
> > >
> > > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> > > >
> > > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> >
On Fri, Oct 9, 2020 at 10:06 AM Dilip Kumar wrote:
>
> On Fri, Oct 9, 2020 at 8:40 AM Amit Kapila wrote:
> >
> > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> > >
> > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> > >
> > > > > This script will wait 10 seconds after INSERT exits
> >
On Fri, Oct 9, 2020 at 8:40 AM Amit Kapila wrote:
>
> On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> >
> > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> >
> > > > This script will wait 10 seconds after INSERT exits
> > > > before executing TRUNCATE, please wait for it to run.
> >
> > Ha
On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
>
> On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
>
> > > This script will wait 10 seconds after INSERT exits
> > > before executing TRUNCATE, please wait for it to run.
>
> Has this been tested with anything other than the one test case?
>
> It
On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> > This script will wait 10 seconds after INSERT exits
> > before executing TRUNCATE, please wait for it to run.
Has this been tested with anything other than the one test case?
It would be good to know how the patch handles a transaction that
co
On Thu, Oct 8, 2020 at 2:17 PM Dilip Kumar wrote:
>
> On Thu, Oct 8, 2020 at 2:05 PM Keisuke Kuroda
> wrote:
> >
> > Hi Dilip,
> >
> > > I could not see this issue even without the patch, it is taking less
> > > than 1s even without the patch. See below results
> > >
> > > 2020-10-08 13:00:49 BE
On Thu, Oct 8, 2020 at 2:05 PM Keisuke Kuroda
wrote:
>
> Hi Dilip,
>
> > I could not see this issue even without the patch, it is taking less
> > than 1s even without the patch. See below results
> >
> > 2020-10-08 13:00:49 BEGIN 509
> > 2020-10-08 13:00:49 table nsp_001.part_0001: INSERT:...
> >
Hi Dilip,
> I could not see this issue even without the patch, it is taking less
> than 1s even without the patch. See below results
>
> 2020-10-08 13:00:49 BEGIN 509
> 2020-10-08 13:00:49 table nsp_001.part_0001: INSERT:...
> 2020-10-08 13:00:49 COMMIT 509 (at 2020-10-08 13:00:48.741986+05:30)
>
On Fri, Oct 2, 2020 at 12:26 PM Keisuke Kuroda
wrote:
>
> Hi Dilip, Amit,
>
> > > 5. Can you please once repeat the performance test done by Keisuke-San
> > > to see if you have similar observations? Additionally, see if you are
> > > also seeing the inconsistency related to the Truncate message r
On Fri, Oct 2, 2020 at 12:26 PM Keisuke Kuroda
wrote:
>
> Hi Dilip, Amit,
>
> > > 5. Can you please once repeat the performance test done by Keisuke-San
> > > to see if you have similar observations? Additionally, see if you are
> > > also seeing the inconsistency related to the Truncate message r
Hi Dilip, Amit,
> > 5. Can you please once repeat the performance test done by Keisuke-San
> > to see if you have similar observations? Additionally, see if you are
> > also seeing the inconsistency related to the Truncate message reported
> > by him and if so why?
> >
>
> Okay, I will set up and
On Thu, Oct 1, 2020 at 4:44 PM Amit Kapila wrote:
>
> On Thu, Oct 1, 2020 at 10:12 AM Dilip Kumar wrote:
> >
> > On Wed, Sep 30, 2020 at 3:00 PM Amit Kapila wrote:
> > >
> > > On Wed, Sep 30, 2020 at 12:16 PM Dilip Kumar
> > > wrote:
> >
> > > And you might need to update the below comment as
On Thu, Oct 1, 2020 at 10:12 AM Dilip Kumar wrote:
>
> On Wed, Sep 30, 2020 at 3:00 PM Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 12:16 PM Dilip Kumar wrote:
>
> > And you might need to update the below comment as well:
> > typedef struct ReorderBufferTXN
> > {
> > ..
> > /*
> > * List o
On Thu, Oct 1, 2020 at 2:43 PM Keisuke Kuroda
wrote:
>
> > > I test the patch on the master HEAD(9796f455) and it works fine.
> > > * make installcheck-world: passed
> > > * walsender process continues to use 100% of the CPU 1core when
> > > TRUNCATE 1000 partition: 1s or less
> > > ** before patc
> > I test the patch on the master HEAD(9796f455) and it works fine.
> > * make installcheck-world: passed
> > * walsender process continues to use 100% of the CPU 1core when
> > TRUNCATE 1000 partition: 1s or less
> > ** before patch : 230s
>
> Does this result indicate that it is still CPU bound
On Wed, Sep 30, 2020 at 3:00 PM Amit Kapila wrote:
>
> On Wed, Sep 30, 2020 at 12:16 PM Dilip Kumar wrote:
> >
> > On Mon, Sep 28, 2020 at 2:22 PM Amit Kapila wrote:
> > >
> > >
> > > I don't have a patch for this idea but you can refer [1]
> > > (v25-0002-Issue-individual-invalidations-with-wal
On Thu, Oct 1, 2020 at 9:19 AM Amit Kapila wrote:
>
> On Thu, Oct 1, 2020 at 8:22 AM Keisuke Kuroda
> wrote:
> >
> > Hi Dilip, Amit,
> >
> > Thank you for the patch!
> >
> > I test the patch on the master HEAD(9796f455) and it works fine.
> > * make installcheck-world: passed
> > * walsender proc
On Thu, Oct 1, 2020 at 8:22 AM Keisuke Kuroda
wrote:
>
> Hi Dilip, Amit,
>
> Thank you for the patch!
>
> I test the patch on the master HEAD(9796f455) and it works fine.
> * make installcheck-world: passed
> * walsender process continues to use 100% of the CPU 1core when
> TRUNCATE 1000 partition
Hi Dilip, Amit,
Thank you for the patch!
I test the patch on the master HEAD(9796f455) and it works fine.
* make installcheck-world: passed
* walsender process continues to use 100% of the CPU 1core when
TRUNCATE 1000 partition: 1s or less
** before patch : 230s
There is "ReorderBufferAddInvalid
On Wed, Sep 30, 2020 at 12:16 PM Dilip Kumar wrote:
>
> On Mon, Sep 28, 2020 at 2:22 PM Amit Kapila wrote:
> >
> >
> > I don't have a patch for this idea but you can refer [1]
> > (v25-0002-Issue-individual-invalidations-with-wal_level-lo) to see
> > what I was trying to say about registering the
On Mon, Sep 28, 2020 at 2:22 PM Amit Kapila wrote:
>
> On Mon, Sep 28, 2020 at 10:01 AM Keisuke Kuroda
> wrote:
> >
> > > Okay. Feel free to clarify your questions if you have any? Are you
> > > interested in writing a patch for the same?
> >
> > Thank you! Yes, I would like to write a patch.
> >
Hi Amit,
> I don't have a patch for this idea but you can refer [1]
> (v25-0002-Issue-individual-invalidations-with-wal_level-lo) to see
> what I was trying to say about registering the invalidations in the
> form of ReorderBufferChange. We have something along the lines of what
> I described abov
On Mon, Sep 28, 2020 at 10:01 AM Keisuke Kuroda
wrote:
>
> > Okay. Feel free to clarify your questions if you have any? Are you
> > interested in writing a patch for the same?
>
> Thank you! Yes, I would like to write a patch.
> If you already have a discussed thread or patch for this idea,
> plea
Hi Amit,
> You need to refer to XLOG_XACT_INVALIDATIONS, not XLOG_INVALIDATIONS.
Thank you, that's right. XLOG_INVALIDATIONS is added at COMMIT,
so I need to refer to XLOG_XACT_INVALIDATIONS.
> Okay. Feel free to clarify your questions if you have any? Are you
> interested in writing a patch for
On Mon, Sep 28, 2020 at 7:50 AM Keisuke Kuroda
wrote:
>
> Hi Amit,
>
> Thank you for the reply!
>
> > However, after commit c55040ccd0 (When wal_level=logical,
> > write invalidations at command end into WAL so that decoding can use
> > this information.) we actually know exactly when we need to e
Hi Amit,
Thank you for the reply!
> However, after commit c55040ccd0 (When wal_level=logical,
> write invalidations at command end into WAL so that decoding can use
> this information.) we actually know exactly when we need to execute
> each invalidation.
I see, thank you for your explaination.
On Wed, Sep 23, 2020 at 1:09 PM Keisuke Kuroda
wrote:
>
> Hi hackers,
>
> I found a problem in logical replication.
> It seems to have the same cause as the following problem.
>
> Creating many tables gets logical replication stuck
>
> https://www.postgresql.org/message-id/flat/20f3de7675f831
Hi hackers,
I found a problem in logical replication.
It seems to have the same cause as the following problem.
Creating many tables gets logical replication stuck
https://www.postgresql.org/message-id/flat/20f3de7675f83176253f607b5e199b228406c21c.camel%40cybertec.at
Logical decoding CPU-
38 matches
Mail list logo
