Does changing a column type lock the table?

Yes, and this is the expensive member of the family. It takes an access exclusive lock and normally holds it while it rewrites the whole table and rebuilds every index on it, so the outage lasts as long as the rewrite. The exception is narrow but useful: when the old type is binary coercible to the new one and the conversion does not change the stored bytes, the change is a catalog edit and finishes instantly.

Which changes escape the rewrite

The documented rule is about the stored representation. Widening a variable-length text column, or moving between the text and variable character types, does not alter what is on the page, so there is nothing to rewrite and the indexes keep their contents because the sort order is identical. Narrowing the same column does not qualify, because every value has to be checked.

The exception has a trapdoor. If the collation changes as part of the conversion, the index is ordered by a rule that no longer applies and must be rebuilt regardless of whether the bytes moved. That is the same hazard as an operating system upgrade underneath a running cluster, and it is worth checking before assuming a change is free.

When a rewrite does happen, budget for three things beyond the time: the table is unreadable throughout, the filesystem needs room for a second copy of the table and its indexes at once, and the column’s statistics are discarded. That last one is the quiet damage, because the server comes back available and plans badly until an analyze runs. If you had set a distinct-value override on that column, what it was correcting is gone with the rest.

The migration shape that avoids the outage

Add a new column of the target type, backfill it in batches small enough that no single transaction holds a lock for long, keep both columns in step from the application while the backfill runs, then swap the names in one brief transaction and drop the old one. It is more work and it is interruptible at every step, which is the point.

Whichever route you take, set a lock timeout on the session running the change. Without one, the command waits patiently for the table, and every query arriving behind it waits too, so a statement that would have finished instantly becomes an outage the length of your slowest report. That queueing behaviour is the same one described in does adding a column lock the table, and lock contention and blocking trees covers confirming it after the fact. The strengths themselves are in lock modes.