pgsql: Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot. - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.
Date
Msg-id E1ocYuA-001zu3-6R@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.

Commit 25936fd46 adjusted things so that the "storeslot" we use
for remapping trigger tuples would have adequate lifespan, but it
neglected to consider the lifespan of the tuple descriptor that
the slot depends on.  It turns out that in at least some cases, the
tupdesc we are passing is a refcounted tupdesc, and the refcount for
the slot's reference can get assigned to a resource owner having
different lifespan than the slot does.  That leads to an error like
"tupdesc reference 0x7fdef236a1b8 is not owned by resource owner
SubTransaction".  Worse, because of a second oversight in the same
commit, we'd try to free the same tupdesc refcount again while
cleaning up after that error, leading to recursive errors and an
"ERRORDATA_STACK_SIZE exceeded" PANIC.

To fix the initial problem, let's just make a non-refcounted copy
of the tupdesc we're supposed to use.  That seems likely to guard
against additional problems, since there's no strong reason for
this code to assume that what it's given is a refcounted tupdesc;
in which case there's an independent hazard of the tupdesc having
shorter lifespan than the slot does.  (I didn't bother trying to
free said copy, since it should go away anyway when the (sub)
transaction context is cleaned up.)

The other issue can be fixed by making the code added to
AfterTriggerFreeQuery work like the rest of that function, ie be
sure that it doesn't try to free the same slot twice in the event
of recursive error cleanup.

While here, also clean up minor stylistic issues in the test case
added by 25936fd46: don't use "create or replace function", as any
name collision within the tests is likely to have ill effects
that that won't mask; and don't use function names as generic as
trigger_function1, especially if you're not going to drop them
at the end of the test stanza.

Per bug #17607 from Thomas Mc Kay.  Back-patch to v12, as the
previous fix was.

Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/216f9c1ab3a4f333632ce576e1dc1e3643427eb8

Modified Files
--------------
src/backend/commands/trigger.c         | 15 +++++++++---
src/test/regress/expected/triggers.out | 38 +++++++++++++++++++++++-----
src/test/regress/sql/triggers.sql      | 45 +++++++++++++++++++++++++++++-----
3 files changed, 82 insertions(+), 16 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Avoid loss of code coverage with unlogged-index test cases.
Next
From: Michael Paquier
Date:
Subject: pgsql: Refactor creation of backup_label and backup history files