Re: Detecting schema changes during logical replication

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

In response to

Responses

Browse pgsql-hackers by date

  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