> 20 дек. 2019 г., в 06:39, Tomas Vondra <tomas.von...@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 error reporting. 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.
0001-Avoid-duplication-in-relcache-and-syscache-callbacks.patch
Description: Binary data
