On 2019-11-12 02:11, Amit Langote wrote:
>> I don't understand why you go through great lengths to ensure that the
>> relkinds match between publisher and subscriber. We already ensure that
>> only regular tables are published and only regular tables are allowed as
>> subscription target. In the future, we may want to allow further
>> combinations. What situation are you trying to address here?
> I'd really want to see the requirement for relkinds to have to match
> go away, but as you can see, this patch doesn't modify enough of
> pgoutput.c and worker.c to make that possible. Both the code for the
> initital syncing and that for the subsequent real-time replication
> assume that both source and target are regular tables. So even if
> partitioned tables can now be in a publication, they're never sent in
> the protocol messages, only their leaf partitions are. Initial
> syncing code can be easily modified to support any combination of
> source and target relations, but changes needed for real-time
> replication seem non-trivial. Do you think we should do that before
> we can say partitioned tables support logical replication?
My question was more simply why you have this check:
+ /*
+ * Cannot replicate from a regular to a partitioned table or vice
+ * versa.
+ */
+ if (local_relkind != pt->relkind)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("cannot use relation \"%s.%s\" as logical
replication target",
+ rv->schemaname, rv->relname),
It doesn't seem necessary. What happens if you remove it?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
