Identity #421
Identity #421
Conversation
codabrink
force-pushed
the
coda/identity
branch
from
e28451b to
27ef6c8
Compare
codabrink
force-pushed
the
coda/identity
branch
from
f3d92c6 to
57ba1c6
Compare
| SET | ||
| NOT NULL; | ||
|
|
||
| CREATE INDEX idx_address_log_identifier_inbox_id ON address_log (identifier, identifier_kind, inbox_id); |
There was a problem hiding this comment.
@neekolas Do you think removing and adding a new index on this table will be an issue?
There was a problem hiding this comment.
I don't think it's a huge deal because the table is relatively small. But it will block the node from coming up until it's completed.
Would be better if we could add the index concurrently, but IIRC we get errors doing that because it happens in a transaction
There was a problem hiding this comment.
CREATE INDEX CONCURRENTLY is what you might want. It takes twice as long, but it does not block concurrent transactions. I don't know whether the newest version of PG still releases the table lock and commits the ongoing transaction implicitly or not.
Since its a secondary non-unique index, you don't really care if it does not exist for a period of time. It will just make some queries slower.
There was a problem hiding this comment.
From my recollection we can't use it in our migrations because the migration runner wraps everything in a transaction, and transactions can't create indexes concurrently. But my knowledge of this codebase is very out of date and maybe the issue is resolved.
You can try it. If the issue is still there every test that touches the DB will fail.
| -- Default all of the existing identifier_kinds to 1 (Ethereum) | ||
| UPDATE address_log | ||
| SET | ||
| identifier_kind = 1; | ||
|
|
||
| ALTER TABLE address_log | ||
| ALTER COLUMN identifier_kind | ||
| SET | ||
| NOT NULL; |
There was a problem hiding this comment.
I don't know the internals of PG well enough to remember whether alter table holds an exclusive table lock or not. If an insert happens between the UPDATE and the ALTER, it will have a null column. There has to be a way to do it in one statement...
There was a problem hiding this comment.
I would do it like this
ALTER TABLE address_log ADD COLUMN identifier_kind INT DEFAULT 1;
UPDATE address_log SET identifier_kind = 1 WHERE identifier_kind IS NULL;
ALTER TABLE address_log ALTER COLUMN identifier_kind SET NOT NULL;
There was a problem hiding this comment.
You're right, I did write this with the assumption that the migration holds an exclusive lock. I can just be safe and use your approach.
No description provided.