Date: Mon, 2 May 2022 12:55:10 +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: <202205021055.kobwph2lidwi@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <37755ade-9fae-fec0-6602-e5b496c2a95c@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202205021055.kobwph2lidwi%40alvherre.pgsql>
Precedence: bulk

On 2022-May-02, Tomas Vondra wrote:

> On 5/2/22 12:17, Alvaro Herrera wrote:

> > The latter ultimately means that we aren't sure that a combined
> > subscription is safe.  And in turn this means that a pg_dump of such a
> > database cannot be restored (because the CREATE SUBSCRIPTION will be
> > rejected as being inconsistent).
> 
> We could do this check when executing the START_REPLICATION command, no?

Ah!  That sounds like it might work: we throw WARNINGs are CREATE
SUBSCRIPTION (so that users are immediately aware in case something is
going to fail later, but the objects are still created and they can fix
the publications afterwards), but the real ERROR is in START_REPLICATION.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"