Re:Pgroll: zero-downtime, undoable, schema migrations for Po...
by candiddevmike on Tuesday October 03, 2023 @04:44PM
(#37757294)
The locks I was referring to were more around advisory locks to prevent multiple migrations from running. For the locks you mention, all migrations create some kind of table lock typically, it's up to the dev to make them as small as necessary. I don't follow your strawman.
[ Parent
| on HN ]
Re:Pgroll: zero-downtime, undoable, schema migrations for Po...
by bananapub on Tuesday October 03, 2023 @05:55PM
(#37758138)
> I don't follow your strawman.
how large are the DB migrations you've done? your experience is seemingly completely different to mine.
Re:Pgroll: zero-downtime, undoable, schema migrations for Po...
by ttfkam on Tuesday October 03, 2023 @06:43PM
(#37758600)
The locks I was referring to were a direct result of many (most?) ALTER statements. Multiple clients trying to migrate isn't even in this equation. Just one client migrating can ruin your day with a single ALTER statement given a large enough database.
What's the biggest table you've ever had to modify?
Adding a column with a default is easy. What about deleting a column from a table with 10s of millions of rows? Renaming a column? Changing a column's type? Adding a CHECK constraint? Adding a NOT NULL? Adding a foreign key constraint that someone accidentally removed in the previous migration while data keeps flowing?
Those concerns aren't about your explicit advisory locks. Not by a long shot.
https://www.postgresql.org/docs/current/explicit-locking.htm...