Re: Two bugs around ALTER TYPE

Hi Andrey,

Thanks for the patch series. I was able to reproduce both bugs on master at
HEAD and verified each fix end-to-end:

A couple of points:
Bug 1: "Number of returned columns (2) does not match expected column count
(3) on the second call.
With 0002 patch, it returns the new 3-column shape as expected.

Bug 2 (with only 0004 patch): Session A returns (1,2), DDL commits after,
next call returns (1,2,99). Mechanism works as designed.

I also confirmed why glob->relationOids is the right channel rather than
glob->invalItems via record_plan_type_dependency(): ALTER TYPE ADD
ATTRIBUTE
on a composite goes through ALTER TABLE on typrelid and modifies
pg_class/pg_attribute but not the composite's pg_type row, so no TYPEOID
syscache invalidation fires
(CacheInvalidateHeapTuple in AlterDomainAddConstraint).
relcache-on-typrelid is the only channel that actually delivers, which is
what the patch hooks into.

A few comments:
1. 0003 patch alone leaves a permanently-failing TAP test (its expected
1|2|99 is only producible by 0004's lock forcing the DDL to
wait). Maybe equash 0003 patch into 0004 patch.

2. alter_table.sql comment says the fix records typrelid in "the plan's
invalItems"; it actually goes into glob->relationOids
different list, different callback (PlanCacheRelCallback vs
PlanCacheObjectCallback).

3. TAP test in 0004 captures $ddl_pid via pg_backend_pid() (lines 68-69)
but never uses it.
Either we can drop, or use it to assert the DDL session is genuinely
waiting on the typrelid in pg_locks
(granted=false on AccessExclusiveLock). The latter would directly verify
the lock instead of just observing the symptom.

Regards,
Surya Poondla