Re: logical decoding and replication of sequences, take 2 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: logical decoding and replication of sequences, take 2
Date
Msg-id CAA4eK1LBgxrti5tpu5dOE0z9SyOYvozKZNugU14mYmC32qG6mQ@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding and replication of sequences, take 2  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Mar 16, 2023 at 1:08 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 15, 2023 at 9:52 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> >
> >
> >
> > On 3/14/23 08:30, John Naylor wrote:
> ---
> I got an assertion failure. The reproducible steps are:
>
> 1. On publisher
> alter system set logical_replication_mode = 'immediate';
> select pg_reload_conf();
> create publication test_pub for all sequences;
>
> 2. On subscriber
> create subscription test_sub connection 'dbname=postgres port=5551'
> publication test_pub with (streaming='parall\el')
>
> 3. On publisher
> begin;
> create table bar (c int, d serial);
> insert into bar(c) values (100);
> commit;
>
> I got the following assertion failure:
>
> TRAP: failed Assert("(!seq.transactional) || in_remote_transaction"),
...
>
> seq.transactional is true and in_remote_transaction is false. It might
> be an issue of the parallel apply feature rather than this patch.
>

During parallel apply we didn't need to rely on in_remote_transaction,
so it was not set. I haven't checked the patch in detail but am
wondering, isn't it sufficient to instead check IsTransactionState()
and or IsTransactionOrTransactionBlock()?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [EXTERNAL] Support load balancing in libpq
Next
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements