Skip to content

Commit 344a225

Browse files
committed
Fix breakage in AlterFunction().
An ALTER FUNCTION command that tried to update both the function's proparallel property and its proconfig list failed to do the former, because it stored the new proparallel value into a tuple that was no longer the interesting one. Carelessness in 7aea8e4. (I did not bother with a regression test, because the only likely future breakage would be for someone to ignore the comment I added and add some other field update after the heap_modify_tuple step. A test using existing function properties could not catch that.) Per report from Bryn Llewellyn. Back-patch to all supported branches. Discussion: https://postgr.es/m/8AC9A37F-99BD-446F-A2F7-B89AD0022774@yugabyte.com
1 parent 83cca40 commit 344a225

File tree

1 file changed

+3
-2
lines changed

1 file changed

+3
-2
lines changed

src/backend/commands/functioncmds.c

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1472,6 +1472,8 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
14721472

14731473
procForm->prosupport = newsupport;
14741474
}
1475+
if (parallel_item)
1476+
procForm->proparallel = interpret_func_parallel(parallel_item);
14751477
if (set_items)
14761478
{
14771479
Datum datum;
@@ -1506,8 +1508,7 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
15061508
tup = heap_modify_tuple(tup, RelationGetDescr(rel),
15071509
repl_val, repl_null, repl_repl);
15081510
}
1509-
if (parallel_item)
1510-
procForm->proparallel = interpret_func_parallel(parallel_item);
1511+
/* DO NOT put more touches of procForm below here; it's now dangling. */
15111512

15121513
/* Do the update */
15131514
CatalogTupleUpdate(rel, &tup->t_self, tup);

0 commit comments

Comments
 (0)