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" - Mailing list pgsql-hackers

From Neha Sharma
Subject 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"
Date
Msg-id CANiYTQu8uufmGyuVf6UUNc8_WdBq5V4ba0G-OPZU58cftMPyKA@mail.gmail.com
Whole thread Raw
In response to 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"  (Michael Paquier <michael@paquier.xyz>)
Responses 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"  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
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@paquier.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

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Fabien COELHO
Date:
Subject: Re: Patch to document base64 encoding