Re: [Logical Replication] TRAP: FailedAssertion("rel->rd_rel->relreplident == REPLICA_IDENTITY_DEFAULT || rel->rd_rel->relreplident == REPLICA_IDENTITY_FULL || rel->rd_rel->relreplident == REPLICA_IDENTITY_INDEX"

Hi Michael,
Thanks for looking into the issue. Sorry by mistake I had mentioned the
incorrect DML query,please use the query as mentioned below.

On Thu, Jan 9, 2020 at 11:38 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, Jan 07, 2020 at 05:38:49PM +0530, Neha Sharma wrote:
> > I am getting a server crash on publication server on HEAD for the below
> > test case.
> >
> > Test case:
> > Publication server:
> > create table test(a int);
> > create publication test_pub for all tables;
> > alter table test replica identity NOTHING ;
> >
> > Subscription server:
> > create table test(a int);
> > create subscription test_sub CONNECTION 'host=172.16.208.32 port=5432
> > dbname=postgres user=centos' PUBLICATION test_pub WITH ( slot_name =
> > test_slot_sub);
> >
> > Publication server:
> > insert into test values(generate_series(1,5),'aa');
>
insert into test values(generate_series(1,5));

>
> This would not work as your relation has only one column. There are
> some TAP tests for logical replication (none actually stressing
> NOTHING as replica identity), which do not fail, and I cannot
> reproduce the failure myself.
>
> > After executing the DML in publication server ,it crashed with the
> > mentioned assert.
>
> Do you have other objects defined on your schema on the publication or
> the subscription side? Like, er, triggers?
>
I had only one table in the publication server.

I am able to reproduce the issue consistently.

2020-01-09 07:14:31.727 UTC [20436] LOG: logical decoding found consistent
point at 0/1632FC0
2020-01-09 07:14:31.727 UTC [20436] DETAIL: There are no running
transactions.
*TRAP: FailedAssertion("rel->rd_rel->relreplident ==
REPLICA_IDENTITY_DEFAULT || rel->rd_rel->relreplident ==
REPLICA_IDENTITY_FULL || rel->rd_rel->relreplident ==
REPLICA_IDENTITY_INDEX", File: "proto.c", Line: 148)*
postgres: walsender centos 172.16.208.32(40324)
idle(ExceptionalCondition+0x53)[0x8ca453]
postgres: walsender centos 172.16.208.32(40324) idle[0x74c515]
/home/centos/PG_master/postgresql/inst/lib/pgoutput.so(+0x2114)[0x7fb105038114]
postgres: walsender centos 172.16.208.32(40324) idle[0x747fa8]
postgres: walsender centos 172.16.208.32(40324)
idle(ReorderBufferCommit+0x12ee)[0x75187e]
postgres: walsender centos 172.16.208.32(40324) idle[0x7455a8]
postgres: walsender centos 172.16.208.32(40324)
idle(LogicalDecodingProcessRecord+0x2ea)[0x74593a]
postgres: walsender centos 172.16.208.32(40324) idle[0x766c24]
postgres: walsender centos 172.16.208.32(40324) idle[0x7693a2]
postgres: walsender centos 172.16.208.32(40324)
idle(exec_replication_command+0xbb1)[0x76a091]
postgres: walsender centos 172.16.208.32(40324)
idle(PostgresMain+0x4b9)[0x7b1099]
postgres: walsender centos 172.16.208.32(40324) idle[0x482bc7]
postgres: walsender centos 172.16.208.32(40324)
idle(PostmasterMain+0xdbf)[0x73339f]
postgres: walsender centos 172.16.208.32(40324) idle(main+0x44f)[0x48403f]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fb115ded3d5]
postgres: walsender centos 172.16.208.32(40324) idle[0x4840a6]
2020-01-09 07:14:32.055 UTC [20357] LOG: server process (PID 20436) was
terminated by signal 6: Aborted

> --
> Michael
>