]> granicus.if.org Git - postgresql/commit
Fix corruption of tableElts list by MergeAttributes().
authorRobert Haas <rhaas@postgresql.org>
Fri, 19 May 2017 19:02:16 +0000 (15:02 -0400)
committerRobert Haas <rhaas@postgresql.org>
Fri, 19 May 2017 19:02:16 +0000 (15:02 -0400)
commitac8d7e1b834e252c9aa8d5750f70a86ca74228b8
tree2023d4755d5ce7d2332560e931827383a7db8ee0
parent7f17ae0ad07a76eeb1b26e7aa8c4539ce14b253b
Fix corruption of tableElts list by MergeAttributes().

Since commit e7b3349a8ad7afaad565c573fbd65fb46af6abbe, MergeAttributes
destructively modifies the input List, to which the caller's
CreateStmt still points.  One may wonder whether this was already a
bug, but commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 made things
noticeably worse by adding additional destructive modifications so
that the caller's List might, in the case of creation a partitioned
table, no longer even be structurally valid.  Restore the status quo
ante by assigning the return value of MergeAttributes back to
stmt->tableElts in the caller.

In most of the places where DefineRelation is called, it doesn't
matter what stmt->tableElts points to here or whether it's valid or
not, because the caller doesn't use the statement for anything after
DefineRelation returns anyway.  However, ProcessUtilitySlow passes it
to EventTriggerCollectSimpleCommand, and that function tries to invoke
copyObject on it.  If any of the CreateStmt's substructure is invalid
at that point, undefined behavior will result.

One might wonder whether this whole area needs further revision -
perhaps DefineRelation() ought not to be destructively modifying the
caller-provided CreateStmt at all.  However, that would be a behavior
change for any event triggers using C code to inspect the CreateStmt,
so for now, just fix the crash.

Report by Amit Langote, who provided a somewhat different patch for it.

Discussion: http://postgr.es/m/bf6a39a7-100a-74bd-1156-3c16a1429d88@lab.ntt.co.jp
src/backend/commands/tablecmds.c