RE: Conflict detection for update_deleted in logical replication
От | Hayato Kuroda (Fujitsu) |
---|---|
Тема | RE: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | OSCPR01MB14966269726272F2F2B2BD3B0F5B22@OSCPR01MB14966.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Conflict detection for update_deleted in logical replication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Список | pgsql-hackers |
Dear Hou, Thanks for updating the patch! I can finally come back to the thread. Regarding the max_retain_conflict_duration, I prefer GUC approach because it has already had a mechanism for converting unit: subscription option does not have it. Below part contains my comments: 01. check_new_cluster_subscription_configuration ``` @@ -2024,6 +2025,7 @@ check_new_cluster_subscription_configuration(void) PGresult *res; PGconn *conn; int max_active_replication_origins; + int max_replication_slots; ``` I feel max_replication_slots is needed when old_cluster.sub_retain_conflict_info is true. 02. check_old_cluster_for_valid_slots ``` + /* + * The name "pg_conflict_detection" (defined as + * CONFLICT_DETECTION_SLOT) has been reserved for logical + * replication conflict detection since PG18. + */ + if (GET_MAJOR_VERSION(new_cluster.major_version) >= 1800 && + strcmp(slot->slotname, "pg_conflict_detection") == 0) ``` IIUC, we can assume that the vesion of new_cluster is same as pg_upgrade, so no need to check the major version here. 03. Can we add a test for upgrading subscriber node with retain_conflict_info in 004_subscription? Best regards, Hayato Kuroda FUJITSU LIMITED
В списке pgsql-hackers по дате отправления: