[BackendArchitectX]

What changed?

Optimized PostgreSQL visibility schema migrations v1.7 and v1.8 to reduce redundant rewrites of the executions_visibility table.

• v1.7: Grouped four stored generated-column additions into a single ALTER TABLE statement.
• v1.8: Grouped three deployment-related generated-column additions into a single ALTER TABLE statement for upgrades from historical v1.7 schemas.
• Added IF NOT EXISTS to support retries when columns have already been created.
• Preserved the existing generated expressions and index definitions.
• Added structural regression tests to protect the migration layout and column definitions.

Result: A v1.6 → v1.8 upgrade now requires one table rewrite instead of four.

Closes #12923.

Why?

Adding a GENERATED ALWAYS AS (...) STORED column requires PostgreSQL to rewrite the underlying table.

Previously, separate ALTER TABLE statements caused repeated full-table rewrites, extending the ACCESS EXCLUSIVE lock and potentially disrupting workflow visibility queries during upgrades.

Combining the column additions eliminates redundant rewrites without changing the intended schema or index definitions.

This follows the optimization pattern previously applied to later PostgreSQL visibility migrations.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

PostgreSQL migration compatibility

• PostgreSQL 13.5 and 16.15: successful upgrades from visibility schema v1.6 to v1.8.
• Historical v1.7 → optimized v1.8: successful upgrade.
• Historical Temporal SQL tools v1.26.3 and v1.27.1: compatibility verified.
• Interrupted migration followed by retry: recovery completed without an additional table rewrite.
• Validated generated-column expressions, index definitions, index validity and data integrity.
• Verified zero generated-value mismatches in seeded database tests.

Rewrite-count regression

Test dataset	Original	Optimized
10,000 executions	4 rewrites	1 rewrite
100,000 executions	4 rewrites	1 rewrite

Rewrite counts were verified through local PostgreSQL database experiments. The benchmarks are single-run measurements, not statistically controlled performance comparisons.

Go regression tests

GOMAXPROCS=2 go test -p 2 ./schema ./tools/common/schema -count=1

Both packages passed before and after rebasing onto upstream main.

Potential risks

• Exclusive locking remains: The single remaining table rewrite still requires an ACCESS EXCLUSIVE lock. Large production tables may require an upgrade maintenance window.
• Earlier column creation: The optimized v1.7 migration introduces deployment generated columns earlier. Historical v1.7 → v1.8 compatibility was tested.
• Schema drift: IF NOT EXISTS checks column existence but does not validate the type or expression of a pre-existing column. Broader drift detection is outside this change.
• Test coverage: The new automated Go test validates migration structure. Database rewrite counts were verified experimentally but are not currently asserted by CI.