Re: [HACKERS] Detecting schema changes during logical replication
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Detecting schema changes during logical replication |
Дата | |
Msg-id | 20170507190432.kx7piwmjttmfm6px@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [HACKERS] Detecting schema changes during logical replication (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: [HACKERS] Detecting schema changes during logical replication
|
Список | pgsql-hackers |
Hi, On 2017-05-07 19:27:08 +0100, Daniele Varrazzo wrote: > I'm putting together a replication system based on logical > replication. Interesting. If you very briefly could recap what it's about... ;) > I would like to send table information only the first > time a table is seen by the 'change_cb' callback, but of course there > could be some schema change after replication started. So I wonder: is > there any information I can find in the 'Relation' structure of the > change callback, which may suggest that there could have been a change > in the table schema, hence a new schema should be sent to the client? The best way I can think of - which is also what is implemented in the in-core replication framework - is to have a small cache on-top of the relcache. That cache is kept coherent using CacheRegisterRelcacheCallback(). Then whenever there's a change you look up that change in that cache, and send the schema information if it's been invalidated since you last sent something. That's also how the new stuff in v10 essentially works: src/backend/replication/pgoutput/pgoutput.c pgoutput_change(), does a lookup for its own metadata using get_rel_sync_entry() which then checks relentry->schema_sent. Invalidation unsets schema_sent in rel_sync_cache_relation_cb. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: