Date: Mon, 2 May 2022 19:51:54 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: bogus: logical replication rows/cols combinations
Message-ID: <202205021751.aosyba2mh7bc@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <da8a10c1-25b6-29b5-19bd-649a9c9ad0be@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202205021751.aosyba2mh7bc%40alvherre.pgsql>
Precedence: bulk

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"