> 20 дек. 2019 г., в 06:39, Tomas Vondra <tomas.vondra@2ndquadrant.com> написал(а):
>
> 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.
Sorry for bumping old thread.
I was involved in troubleshooting logical replication recently. And found out that it sometimes has a really annoying
errorreporting.
While source of the problem was allegedly in low max_replication_slots, users were getting only this error about
relcache_callback_list.
Maybe we could fix this particular error by deduplicating callbacks?
Best regards, Andrey Borodin.
