Fix use-after-free bug when renaming constraints
This is an oversight from recent commit b13fd344
. While on it, tweak
the previous test with a better name for the renamed primary key.
Detected by buildfarm member prion which forces relation cache release
with -DRELCACHE_FORCE_RELEASE. Back-patch down to 9.4 as the previous
commit.
This commit is contained in:
parent
b13fd344c5
commit
67915fb8e5
|
@ -3020,12 +3020,12 @@ rename_constraint_internal(Oid myrelid,
|
|||
|
||||
if (targetrelation)
|
||||
{
|
||||
relation_close(targetrelation, NoLock); /* close rel but keep lock */
|
||||
|
||||
/*
|
||||
* Invalidate relcache so as others can see the new constraint name.
|
||||
*/
|
||||
CacheInvalidateRelcache(targetrelation);
|
||||
|
||||
relation_close(targetrelation, NoLock); /* close rel but keep lock */
|
||||
}
|
||||
|
||||
return address;
|
||||
|
|
|
@ -400,7 +400,7 @@ CREATE TABLE constraint_rename_cache (a int,
|
|||
ALTER TABLE constraint_rename_cache
|
||||
RENAME CONSTRAINT chk_a TO chk_a_new;
|
||||
ALTER TABLE constraint_rename_cache
|
||||
RENAME CONSTRAINT constraint_rename_cache_pkey TO chk_a_gt_zero;
|
||||
RENAME CONSTRAINT constraint_rename_cache_pkey TO constraint_rename_pkey_new;
|
||||
CREATE TABLE like_constraint_rename_cache
|
||||
(LIKE constraint_rename_cache INCLUDING ALL);
|
||||
\d like_constraint_rename_cache
|
||||
|
|
|
@ -296,7 +296,7 @@ CREATE TABLE constraint_rename_cache (a int,
|
|||
ALTER TABLE constraint_rename_cache
|
||||
RENAME CONSTRAINT chk_a TO chk_a_new;
|
||||
ALTER TABLE constraint_rename_cache
|
||||
RENAME CONSTRAINT constraint_rename_cache_pkey TO chk_a_gt_zero;
|
||||
RENAME CONSTRAINT constraint_rename_cache_pkey TO constraint_rename_pkey_new;
|
||||
CREATE TABLE like_constraint_rename_cache
|
||||
(LIKE constraint_rename_cache INCLUDING ALL);
|
||||
\d like_constraint_rename_cache
|
||||
|
|
Loading…
Reference in New Issue