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
