From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Detecting schema changes during logical replication |
Date: | 2017-05-07 19:04:32 |
Message-ID: | 20170507190432.kx7piwmjttmfm6px@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-07 19:48:13 | Re: Question about toasting code |
Previous Message | Daniele Varrazzo | 2017-05-07 18:27:08 | Detecting schema changes during logical replication |