MIME-Version: 1.0
References: <CALDaNm0sYZN+E5A9Br3JEBkdWL9t7obSFtNa5_n7h=jokWoB5A@mail.gmail.com>
 <202502041551.f7njlr25ie3u@alvherre.pgsql>
In-Reply-To: <202502041551.f7njlr25ie3u@alvherre.pgsql>
From: vignesh C <vignesh21@gmail.com>
Date: Wed, 5 Feb 2025 12:12:40 +0530
Message-ID: <CALDaNm0EA4zuR+PiNmADGORcADQsPSmYKo=tr4hT=pSrLY1B9A@mail.gmail.com>
Subject: Re: Restrict publishing of partitioned table with a foreign table as partition
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@alvh.no-ip.org>
Cc: Sergey Tatarintsev <s.tatarintsev@postgrespro.ru>, Shlok Kyal <shlok.kyal.oss@gmail.com>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CALDaNm0EA4zuR%2BPiNmADGORcADQsPSmYKo%3Dtr4hT%3DpSrLY1B9A%40mail.gmail.com>
Precedence: bulk

On Tue, 4 Feb 2025 at 21:21, =C3=81lvaro Herrera <alvherre@alvh.no-ip.org> =
wrote:
>
> On 2025-Feb-04, vignesh C wrote:
>
> > We should throw an error for partitioned tables that contain foreign
> > partitions, as this would include the data from these foreign tables
> > during the initial sync, while incremental changes would not be
> > replicated.
>
> Hmm, I would support the idea of allowing partitioned tables containing
> foreign partitions into publications, where only the tuples in
> non-foreign partitions would be transmitted -- both during initial sync
> and during replicated DML.  This way, any partitioned tables with mixed
> local and foreign partitions would work okay for replication.  If the
> subscriber wants the data in the foreign partitions, they can create the
> foreign table on the subscription side and all is well.  From a users
> POV this is probably the most useful.
>
> Another aspect is the case where you create the publication first and
> the foreign table later.  I didn't spot in the proposed patch any code
> that would check whether a publication including this schema exists,
> which we would have to do if we wanted to be watertight about rejecting
> publications with foreign tables.  But I think that would be a bad
> direction to go it.
>
> I'd rather have the table-listing code for publications skip any foreign
> tables.  For instance, GetPubPartitionOptionRelations() and
> PublicationAddTables() should skip tables with relkind RELKIND_FOREIGN.
> The sync code should also silently ignore all foreign tables.

We can maintain the behavior you suggested when the
PUBLISH_VIA_PARTITION_ROOT option is set to false. However, when
PUBLISH_VIA_PARTITION_ROOT is true, the table data is copied from the
root table (as intended by the user), which will also include the
foreign table data. In this case, wouldn=E2=80=99t it be better to throw an
error?

Regards,
Vignesh