citusdata / citusdata/citus

Auto TRUNCATE when distributing a table.

Open
#2,624 7 comments 0 reactions 0 assignees View on GitHub
user_reported
Dominant language
C
Stars
12.8k
Forks
794
Avg merge
2d 14h
Merged PRs (30d)
31

Description

Currently we retain the local data after distributing a table. This blocks fixing some of the issues like #2600 and #1770. However, auto-TRUNCATE when distributing a table isn't straightforward, since it might be referenced from other local tables, and in this case (1) TRUNCATE cascade will lead into data loss, (2) TRUNCATE no-cascade might fail (because of foreign key constraint violation).

We can approach this problem in multiple ways.

1. ~~When distributing a table, fail if truncating no-cascade of local data fails. This will force users to topologically sort their table distribution statements. If there are any cyclic references, users should have already defined the constraints as deferrable anyway, so this case isn't a problem too.~~ this doesn't work since TRUNCATE doesn't work for tables with incoming FK constraints (regardless of whether deleting all rows will violate the constraint or not), unless all truncated in the same command.

2. Defer TRUNCATE to the commit time. If we do this, users can distribute their tables in a transaction block, without worrying about the order of distribution statements.

~~Advantage of 2 is that makes life a bit easier for users when distributing tables, but it also has the disadvantage that if the order of distribution statements doesn't follow the reference graph, then between statements we can have foreign keys from local tables to distributed tables which, and if we query the data at that point we might get some weird error messages (like "Consistency check on SPI tuple count failed").~~

~~Approach 1 reduces the probability of these error messages by forcing users to follow the dependency graph, but doesn't eliminate them completely, e.g. when the constraints are deferable.~~

~~My vote is to implement 1 with proper error messages to help users find the correct order as it is a bit easier to implement, and approach 2 doesn't seem to have a great advantage over it.~~

I'm creating this thread so others can propose ideas and comment on things I've missed in my analysis.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.