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
