Hi,
In apply_handle_truncate, the following comment before ExecuteTruncateGuts
says that it defaults to RESTRICT even if the CASCADE option has been
specified in publisher's TRUNCATE command.
/*
* Even if we used CASCADE on the upstream primary we explicitly default
* to replaying changes without further cascading. This might be later
* changeable with a user specified option.
*/
I tried the following use case to see if that's actually true:
1) Created two tables tbl_pk (primary key), tbl_fk(references tbl_pk
primary key via foreign key) on both publisher and subscriber.
2) In general, TRUNCATE tbl_pk; or TRUNCATE tbl_pk RESTRICT; would fail
because tbl_fk is dependent on tbl_pk.
3) TRUNCATE tbl_pk, tbl_fk; would work because the dependent table is
specified in the command.
4) TRUNCATE tbl_pk CASCADE; would work because of the CASCADE option and
both tbl_pk and tbl_fk are truncated. When this command is run on the
publisher, the CASCADE option is sent to the subscriber, see
DecodeTruncate. But the apply worker ignores it and passes DROP_RESTRICT to
ExecuteTruncateGuts. Therefore, the expectation(per the comment) is that on
the subscriber, the behavior should be equivalent to TRUNCATE tbl_pk;, so
an error is expected. But we are also receiving the tbl_fk in the remote
rels along with tbl_pk, so the behavior is equivalent to (3) and both
tbl_pk and tbl_fk are truncated.
Does the comment still hold true? Does ignoring the CASCADE option make
sense in apply_handle_truncate, as we are receiving all the dependent
relations in the remote rels from the publisher? Am I missing something?
The commit id of the feature "Logical replication support for TRUNCATE" is
039eb6e92f, and adding relevant people in cc.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
