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
I think Squawk shouldn't complain here because there won't be any rows in our table so the lock will be short.
stdin:1:0: warning: adding-foreign-key-constraint
1 | CREATE TABLE IF NOT EXISTS my.table
2 | (
3 | username text primary key,
4 | nickname text not null,
5 | --
6 | --
7 | --
8 | --
9 | --
10 |
11 | CONSTRAINT nickname_fkey
12 | FOREIGN KEY (nickname) REFERENCES some.nickname_table (id)
13 | );
note: Requires a table scan of the table you're altering and a SHARE ROW EXCLUSIVE lock on both tables, which blocks writes to both tables while your table is scanned.
help: Add NOT VALID to the constraint in one transaction and then VALIDATE the constraint in a separate transaction.
find detailed examples and solutions for each rule at https://squawkhq.com/docs/rules
The text was updated successfully, but these errors were encountered:
This addresses sbdchd#220, which claims that although an exclusive lock will
be obtained on the referenced table, there are no rows in the
referencing table so the table scan under the exclusive lock should be
short or non-existent.
I think Squawk shouldn't complain here because there won't be any rows in our table so the lock will be short.
The text was updated successfully, but these errors were encountered: