Skip to content

Commit 08a9e7a

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 7a8d821 commit 08a9e7a

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
@@ -1489,6 +1489,8 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
14891489

14901490
procForm->prosupport = newsupport;
14911491
}
1492+
if (parallel_item)
1493+
procForm->proparallel = interpret_func_parallel(parallel_item);
14921494
if (set_items)
14931495
{
14941496
Datum datum;
@@ -1523,8 +1525,7 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
15231525
tup = heap_modify_tuple(tup, RelationGetDescr(rel),
15241526
repl_val, repl_null, repl_repl);
15251527
}
1526-
if (parallel_item)
1527-
procForm->proparallel = interpret_func_parallel(parallel_item);
1528+
/* DO NOT put more touches of procForm below here; it's now dangling. */
15281529

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

0 commit comments

Comments
 (0)