Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes
| От | Kyotaro Horiguchi | 
|---|---|
| Тема | Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes | 
| Дата | |
| Msg-id | 20230220.170819.1706546447454237643.horikyota.ntt@gmail.com обсуждение исходный текст  | 
		
| Ответ на | "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>) | 
| Ответы | 
                	
            		Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes
            		
            		 | 
		
| Список | pgsql-hackers | 
Good catch! At Sun, 19 Feb 2023 02:40:31 +0000, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com> wrote in > init_rel_sync_cache()), but they are not unregistered when it shutdowns. So, > after multiple calls to the function, MAX_RELCACHE_CALLBACKS is exceeded. This > is mentioned in the following comment. > > /* > * We can get here if the plugin was used in SQL interface as the > * RelSchemaSyncCache is destroyed when the decoding finishes, but there > * is no way to unregister the relcache invalidation callback. > */ > if (RelationSyncCache == NULL) > return; > > Could we fix it by adding two new function to unregister relcache callback and > syscache callback? I tried to do so in the attached patch. I'm pretty sure that everytime an output plugin is initialized on a process, it installs the same set of syscache/relcache callbacks each time. Do you think we could simply stop duplicate registration of those callbacks by using a static boolean? It would be far simpler. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: