Citus does not acquire locks on relations properly when processing truncate commands
- Dominant language
- C
- Stars
- 12.8k
- Forks
- 794
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 31
Description
I realized that we don't acquire any locks on relations to be truncated in `PostprocessTruncateStmt` function (btw it actually seems to be a "preprocess" method before standard process utility).
This might yield several inconsistencies when executing some other ddl commands concurrently like `Drop`.
A quick case to show the "very least bad case" lies below:
If we put a break point to `GetCitusTableCacheEntry` function for `session2`, and do the following:
```sql
--session1--
BEGIN;
DROP TABLE reference_table;
```
```sql
--session2--
BEGIN;
TRUNCATE reference_table;
```
and if we continue execution of `session2` after committing `session1`, we get below error:
```sql
ERROR: relation with OID 1234567 does not exist
```
while it should actually be:
```sql
relation "reference_table" does not exist
```
I didn't think deeply on other possible edge cases but I think this behavior might even lead to crashes or unexpected errors.
Contributor guide
Research direction
Start by tracing PostprocessTruncateStmt and GetCitusTableCacheEntry, then reproduce the two-session DROP and TRUNCATE sequence described in the issue. Investigate relation locking during truncate processing and verify that concurrent deletion reports that the relation does not exist rather than an OID lookup error, without introducing crashes or unexpected errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, postgresql, sql
- Domain
- databases, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100