Re: How is this possible "publication does not exist"
От | Andrey Borodin |
---|---|
Тема | Re: How is this possible "publication does not exist" |
Дата | |
Msg-id | CD822302-A511-4858-8700-3A806EEF9680@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: How is this possible "publication does not exist" (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: How is this possible "publication does not exist"
|
Список | pgsql-hackers |
> 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.
Вложения
В списке pgsql-hackers по дате отправления: