You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Drop partitions of the `parent` table (both foreign and local relations). If `delete_data` is `false`, the data is copied to the parent table first. Default is `false`.
253
253
254
+
To remove partitioned table along with all partitions fully, use conventional
255
+
`DROP TABLE relation CASCADE`. However, care should be taken in somewhat rare
256
+
case when you are running logical replication and `DROP` was executed by
257
+
replication apply worker, e.g. via trigger on replicated table. `pg_pathman`
258
+
uses `pathman_ddl_trigger` event trigger to remove the record about dropped
259
+
table from `pathman_config`, and this trigger by default won't fire on replica,
260
+
leading to inconsistent state when `pg_pathman` thinks that the table still
261
+
exists, but in fact it doesn't. If this is the case, configure this trigger to
262
+
fire on replica too:
263
+
264
+
```plpgsql
265
+
ALTER EVENT TRIGGER pathman_ddl_trigger ENABLE ALWAYS;
266
+
```
267
+
268
+
Physical replication doesn't have this problem since DDL as well as
269
+
`pathman_config` table is replicated too; master and slave PostgreSQL instances
270
+
are basically identical, and it is only harmful to keep this trigger in `ALWAYS`
0 commit comments