On Wed, Oct 12, 2022 at 3:35 PM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Sawada-san,
>
> > FYI, as I just replied to the related thread[1], the assertion failure
> > in REL14 and REL15 can be fixed by the patch proposed there. So I'd
> > like to see how the discussion goes. Regardless of this pro
Dear Sawada-san,
> FYI, as I just replied to the related thread[1], the assertion failure
> in REL14 and REL15 can be fixed by the patch proposed there. So I'd
> like to see how the discussion goes. Regardless of this proposed fix,
> the patch proposed by Kuroda-san is required for HEAD, REL14, an
On Wed, Sep 7, 2022 at 11:06 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Amit,
>
> Thanks for giving comments!
>
> > Did you get this new assertion failure after you applied the patch for
> > the first failure? Because otherwise, how can you reach it with the
> > same test case?
>
> The first fai
Dear Sawada-san,
Thank you for reviewing HEAD patch! PSA v3 patch.
> +# Test that we can force the top transaction to do timetravel when one of sub
> +# transactions needs that. This is necessary when we restart decoding
> from RUNNING_XACT
> +# without the wal to associate subtransaction to its
On Wed, Sep 7, 2022 at 11:06 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Amit,
>
> Thanks for giving comments!
>
> > Did you get this new assertion failure after you applied the patch for
> > the first failure? Because otherwise, how can you reach it with the
> > same test case?
>
> The first fai
Dear Amit,
Thanks for giving comments!
> Did you get this new assertion failure after you applied the patch for
> the first failure? Because otherwise, how can you reach it with the
> same test case?
The first failure is occurred only in the HEAD, so I did not applied the first
patch
to REL14 a
On Tue, Sep 6, 2022 at 1:17 PM kuroda.hay...@fujitsu.com
wrote:
>
> Dear hackers,
>
> > I agreed both that DEBUG2 messages are still useful but we should not
> > change the condition for output. So I prefer the idea suggested by Amit.
>
> PSA newer patch, which contains the fix and test.
>
> > > I
> I was not sure what's the proper way to fix it.
> The solution I've thought at first was transporting all invalidations from
> sub to top
> like ReorderBufferTransferSnapToParent(),
> but I do not know its side effect. Moreover, how do we deal with
> ReorderBufferChange?
> Should we transfer the
Dear hackers,
> I agreed both that DEBUG2 messages are still useful but we should not
> change the condition for output. So I prefer the idea suggested by Amit.
PSA newer patch, which contains the fix and test.
> > I have not verified but I think we need to backpatch this till 14
> > because pri
On Fri, Sep 2, 2022 at 6:26 AM osumi.takami...@fujitsu.com
wrote:
>
>
> I've met an assertion failure of logical decoding with below scenario on HEAD.
>
> ---
>
> create table tab1 (val integer);
> select 'init' from pg_create_logical_replication_slot('regression_slot',
> 'test_decoding');
>
>
> > I'm basically fine, too. But this is a bug that needs back-patching
> > back to 10.
> >
>
> I have not verified but I think we need to backpatch this till 14
> because prior to that in DecodeCommit, we use to set the top-level txn
> as having catalog changes based on the if there are invalidat
On Fri, Sep 2, 2022 at 12:25 PM Kyotaro Horiguchi
wrote:
>
> At Fri, 2 Sep 2022 11:27:23 +0530, Dilip Kumar wrote
> in
> > On Fri, Sep 2, 2022 at 11:25 AM kuroda.hay...@fujitsu.com
> > wrote:
> > > How about following?
> > >
> > > diff --git a/src/backend/replication/logical/snapbuild.c
> > >
At Fri, 2 Sep 2022 11:27:23 +0530, Dilip Kumar wrote in
> On Fri, Sep 2, 2022 at 11:25 AM kuroda.hay...@fujitsu.com
> wrote:
> > How about following?
> >
> > diff --git a/src/backend/replication/logical/snapbuild.c
> > b/src/backend/replication/logical/snapbuild.c
> > index bf72ad45ec..a6305229
On Fri, Sep 2, 2022 at 11:25 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Horiguchi-san, Dilip,
>
> Thank you for replying!
>
> > > It seems that SnapBuildCommitTxn() is already taking care of adding
> > > the top transaction to the committed transaction if any subtransaction
> > > has the catalog
Dear Horiguchi-san, Dilip,
Thank you for replying!
> > It seems that SnapBuildCommitTxn() is already taking care of adding
> > the top transaction to the committed transaction if any subtransaction
> > has the catalog changes, it has just missed setting the flag so I
> > think just setting the fl
At Fri, 2 Sep 2022 10:59:56 +0530, Dilip Kumar wrote in
> On Fri, Sep 2, 2022 at 6:38 AM kuroda.hay...@fujitsu.com
> wrote:
> >
> > Hi Hackers,
> >
> > > Therefore, this leads to the failure for the assert that can check
> > > the consistency that when one sub transaction modifies the catalog,
>
On Fri, Sep 2, 2022 at 6:38 AM kuroda.hay...@fujitsu.com
wrote:
>
> Hi Hackers,
>
> > Therefore, this leads to the failure for the assert that can check
> > the consistency that when one sub transaction modifies the catalog,
> > its top transaction should be marked so as well.
> >
> > I feel we ne
Good catch, and thanks for the patch!
At Fri, 2 Sep 2022 01:08:04 +, "kuroda.hay...@fujitsu.com"
wrote in
> PSA patch that fixes the failure.
> This adds pairs of sub-top transactions to the SnapBuild, and it will be
> serialized and restored.
> The pair will be checked when we mark the Re
Hi Hackers,
> Therefore, this leads to the failure for the assert that can check
> the consistency that when one sub transaction modifies the catalog,
> its top transaction should be marked so as well.
>
> I feel we need to remember the relationship between top transaction and sub
> transaction
>
Hi, hackers
I've met an assertion failure of logical decoding with below scenario on HEAD.
---
create table tab1 (val integer);
select 'init' from pg_create_logical_replication_slot('regression_slot',
'test_decoding');
begin;
savepoint sp1;
insert into tab1 values (1);
checkpoint; -- for
20 matches
Mail list logo
