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
