Thread

Re: START_REPLICATION SLOT causing a crash in an assert build

Jaime Casanova <jcasanov@systemguards.com.ec> — 2022-09-09T17:51:45Z

On Wed, Sep 07, 2022 at 12:39:08PM -0700, Andres Freund wrote:
> Hi,
> 
> On 2022-09-06 18:40:49 -0500, Jaime Casanova wrote:
> > I'm not sure what is causing this, but I have seen this twice. The
> > second time without activity after changing the set of tables in a
> > PUBLICATION.
> 
> Can you describe the steps to reproduce?
> 

I'm still trying to determine that

> Which git commit does this happen on?
> 

6e55ea79faa56db85a2b6c5bf94cee8acf8bfdb8 (Stamp 15beta4) 

> 
> > gdb says that debug_query_string contains:
> > 
> > """
> > START_REPLICATION SLOT "sub_pgbench" LOGICAL 0/0 (proto_version '3', publication_names '"pub_pgbench"')START_REPLICATION SLOT "sub_pgbench" LOGICAL 0/0 (proto_version '3', publication_names '"pub_pgbench"')
> > """
> > 
> > attached the backtrace.
> > 
> 
> > #2  0x00005559bfd4f0ed in ExceptionalCondition (
> >     conditionName=0x5559bff30e20 "namestrcmp(&statent->slotname, NameStr(slot->data.name)) == 0", errorType=0x5559bff30e0d "FailedAssertion", fileName=0x5559bff30dbb "pgstat_replslot.c", 
> >     lineNumber=89) at assert.c:69
> 
> what are statent->slotname and slot->data.name?
> 

slot->data.name seems to be the replication_slot record, and
statent->slotname comes from the in shared memory stats for that slot.

And the assert happens when &statent->slotname.data comes empty, which 
is not frequent but it happens from time to time

btw, while I'm looking at this I found that we can drop a publication
while there are active subscriptions pointing to it, is that something
we should allow?
anyway, that is not the cause of this because the replication slot actually
exists.

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL