Re: bogus: logical replication rows/cols combinations - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: bogus: logical replication rows/cols combinations
Date
Msg-id 202205021751.aosyba2mh7bc@alvherre.pgsql
Whole thread Raw
In response to Re: bogus: logical replication rows/cols combinations  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: bogus: logical replication rows/cols combinations  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On 2022-May-02, Tomas Vondra wrote:

> pgoutput.c is relies on relcache callbacks to get notified of changes.
> See the stuff that touches replicate_valid and publications_valid. So
> the walsender should notice the changes immediately.

Hmm, I suppose that makes any changes easy enough to detect.  We don't
need a separate signalling mechanism.

But it does mean that the walsender needs to test the consistency of
[rowfilter, column list, published actions] whenever they change for any
of the current publications and it is working for more than one, and
disconnect if the combination no longer complies with the rules.  By the
next time the replica tries to connect, START_REPLICATION will throw the
error.

> Why would we need to know publications replicated by other walsenders?
> And what if the subscriber is not connected at the moment? In that case
> there'll be no walsender.

Sure, if the replica is not connected then there's no issue -- as you
say, that replica will fail at START_REPLICATION time.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La gente vulgar sólo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: avoid multiple hard links to same WAL file after a crash
Next
From: Bharath Rupireddy
Date:
Subject: Is Dynamic Tracing in Postgres running on Ubuntu a good choice?