Re: How is this possible "publication does not exist"

I've been running into a similar issue and am a little puzzled by it,
especially since it survives restarts.

On Fri, Dec 20, 2019 at 2:39 AM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> Yeah, I don't see this error message anywhere in our sources on 11 or
> 12, so perhaps debezium does something funny? It's not clear to me
> where, though, as this suggests it uses the pgoutput module.

The error message comes from GetPublicationByName and the context is
added by output_plugin_error_callback in logical.c. Stack trace of
where the error occurs below.

# SELECT * FROM pg_publication;
    pubname    | pubowner | puballtables | pubinsert | pubupdate |
pubdelete | pubtruncate
----------------+----------+--------------+-----------+-----------+-----------+-------------
 migration_pub |       10 | f            | t         | t         | t         | t
(1 row)

# SELECT * FROM pg_replication_slots ;
   slot_name    |  plugin  | slot_type | datoid | database | temporary
| active | active_pid | xmin | catalog_xmin | restart_lsn |
confirmed_flush_lsn

----------------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
 migration_slot | pgoutput | logical   |  13121 | postgres | f
| f      |            |      |        17153 | 0/CDFC840   | 0/CDFC878
(1 row)

#  SELECT * FROM pg_logical_slot_get_binary_changes('migration_slot',
NULL, NULL,'proto_version','1','publication_names','migration_pub');
ERROR:  publication "migration_pub" does not exist
CONTEXT:  slot "migration_slot", output plugin "pgoutput", in the
change callback, associated LSN 0/CDFC878

#0  errstart (elevel=elevel@entry=20,
filename=filename@entry=0x5581958a6c70 "pg_publication.c",
lineno=lineno@entry=401,
    funcname=funcname@entry=0x5581958a6ea0 <__func__.24991>
"GetPublicationByName", domain=domain@entry=0x0) at elog.c:251
#1  0x00005581954771e5 in GetPublicationByName (pubname=0x558196d107a0
"migration_pub", missing_ok=missing_ok@entry=false) at
pg_publication.c:401
#2  0x00007f77ba1cd704 in LoadPublications (pubnames=<optimized out>)
at pgoutput.c:467
#3  0x00007f77ba1cd7e3 in get_rel_sync_entry
(data=data@entry=0x558196cedee8, relid=<optimized out>) at
pgoutput.c:559
#4  0x00007f77ba1cdb52 in pgoutput_change (ctx=0x558196d7b4f8,
txn=<optimized out>, relation=0x7f77ba1e67c8, change=0x558196cdbab8)
at pgoutput.c:315
#5  0x000055819566a2e6 in change_cb_wrapper (cache=<optimized out>,
txn=<optimized out>, relation=<optimized out>, change=<optimized out>)
at logical.c:747
#6  0x0000558195675785 in ReorderBufferCommit (rb=0x558196d35d38,
xid=xid@entry=17153, commit_lsn=215994160, end_lsn=<optimized out>,
    commit_time=commit_time@entry=662061745906576,
origin_id=origin_id@entry=0, origin_lsn=0) at reorderbuffer.c:1592
#7  0x0000558195667407 in DecodeCommit (ctx=ctx@entry=0x558196d7b4f8,
buf=buf@entry=0x7ffd61faae60, parsed=parsed@entry=0x7ffd61faacf0,
xid=17153) at decode.c:641
#8  0x00005581956675a0 in DecodeXactOp (ctx=0x558196d7b4f8,
buf=buf@entry=0x7ffd61faae60) at decode.c:249
#9  0x00005581956684cb in LogicalDecodingProcessRecord
(ctx=ctx@entry=0x558196d7b4f8, record=<optimized out>) at decode.c:117
#10 0x000055819566c108 in pg_logical_slot_get_changes_guts
(fcinfo=0x7ffd61fab120, confirm=confirm@entry=true,
binary=binary@entry=true) at logicalfuncs.c:309
#11 0x000055819566c35d in pg_logical_slot_get_binary_changes
(fcinfo=<optimized out>) at logicalfuncs.c:391

cheers,
Marco