diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-22 13:32:40 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-22 13:32:40 -0500 |
commit | d8fbbb925bdb8ca1c8eb8572192f4ee199f4d276 (patch) | |
tree | c84c9decd47df56bd9dcbddc8f54f8a6ff8b2c77 /src/backend/access/gist/gist.c | |
parent | 1f655fdc39352c813a83a0a0f1e932af9ef2b6de (diff) | |
download | postgresql-d8fbbb925bdb8ca1c8eb8572192f4ee199f4d276.tar.gz postgresql-d8fbbb925bdb8ca1c8eb8572192f4ee199f4d276.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/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions