|From:||Andrey Borodin <x4mmm(at)yandex-team(dot)ru>|
|To:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, 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"|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 20 дек. 2019 г., в 06:39, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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.
|Next Message||Ranier Vilela||2021-07-23 11:07:10||Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)|
|Previous Message||Amit Kapila||2021-07-23 10:58:03||Re: Avoiding data loss with synchronous replication|