aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeHash.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-01-22 13:32:40 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2022-01-22 13:32:40 -0500
commite2d53c8767da9f98c7c4c8d0b129171848472c93 (patch)
treef3649bdf02691b2c34e897231a7497c3691e55f6 /src/backend/executor/nodeHash.c
parent5521d8139fbdb15f1bf25afae22e7e6d196669e0 (diff)
downloadpostgresql-e2d53c8767da9f98c7c4c8d0b129171848472c93.tar.gz
postgresql-e2d53c8767da9f98c7c4c8d0b129171848472c93.zip
Flush table's relcache during ALTER TABLE ADD PRIMARY KEY USING INDEX.
Previously, unless we had to add a NOT NULL constraint to the column, this command resulted in updating only the index's relcache entry. That's problematic when replication behavior is being driven off the existence of a primary key: other sessions (and ours too for that matter) failed to recalculate their opinion of whether the table can be replicated. Add a relcache invalidation to fix it. This has been broken since pg_class.relhaspkey was removed in v11. Before that, updating the table's relhaspkey value sufficed to cause a cache flush. Hence, backpatch to v11. Report and patch by Hou Zhijie Discussion: https://postgr.es/m/OS0PR01MB5716EBE01F112C62F8F9B786947B9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Diffstat (limited to 'src/backend/executor/nodeHash.c')
0 files changed, 0 insertions, 0 deletions