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

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How is this possible "publication does not exist"
Date: 2019-12-20 01:39:11
Message-ID: 20191220013911.kcx6qydoluao3nle@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Dec 19, 2019 at 07:19:56PM +0100, Peter Eisentraut wrote:
>On 2019-12-19 19:15, Dave Cramer wrote:
>>It seems that if you drop the publication on an existing slot it
>>needs to be recreated. Is this expected behaviour
>A publication is not associated with a slot. Only a subscription is
>associated with a slot.
>>drop publication dbz_publication ;
>>postgres=# create publication dbz_publication for all tables;
>>postgres=# SELECT * FROM
>>pg_logical_slot_get_binary_changes('debezium', NULL,
>>ERROR:  publication "dbz_publication" does not exist
>>CONTEXT:  slot "debezium", output plugin "pgoutput", in the change
>>callback, associated LSN 0/4324180
>This must be something particular to Debezium.

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.

While trying to reproduce this I however ran into a related issue with
pgoutput/pg_logical_slot_get_binary_changes. If you call the function
repeatedly (~10x) you'll get an error like this:

FATAL: out of relcache_callback_list slots
CONTEXT: slot "slot", output plugin "pgoutput", in the startup callback
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

The reason is very simple - each call executes pgoutput_startup, which
does CacheRegisterRelcacheCallback in init_rel_sync_cache. And we do
this on each pg_logical_slot_get_binary_changes() call and never remove
the callbacks, so we simply run out of MAX_RELCACHE_CALLBACKS slots.

Not sure if this is a known issue/behavior, but it seems a bit annoying
and possibly related to the issue reported by Dave.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Wu, Fei 2019-12-20 01:53:44 RE: Is querying SPITupleTable with SQL possible?
Previous Message Smith, Peter 2019-12-20 01:08:47 RE: Proposal: Add more compile-time asserts to expose inconsistencies.