]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Revise RelationBuildRowSecurity() to avoid memory leaks.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 26 Sep 2020 20:04:06 +0000 (16:04 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 26 Sep 2020 20:04:06 +0000 (16:04 -0400)
commitdd89ba5780214e5f0d9b222e242141fe99cfcdd9
tree3a1309c0e486986f9720be2ce619d82bb73a3f44
parent1738a61c8ffe42f987376d2e621d8d823345e1ef
Revise RelationBuildRowSecurity() to avoid memory leaks.

This function leaked some memory while loading qual clauses for
an RLS policy.  While ordinarily negligible, that could build up
in some repeated-reload cases, as reported by Konstantin Knizhnik.
We can improve matters by borrowing the coding long used in
RelationBuildRuleLock: build stringToNode's result directly in
the target context, and remember to explicitly pfree the
input string.

This patch by no means completely guarantees zero leaks within
this function, since we have no real guarantee that the catalog-
reading subroutines it calls don't leak anything.  However,
practical tests suggest that this is enough to resolve the issue.
In any case, any remaining leaks are similar to those risked by
RelationBuildRuleLock and other relcache-loading subroutines.
If we need to fix them, we should adopt a more global approach
such as that used by the RECOVER_RELATION_BUILD_MEMORY hack.

While here, let's remove the need for an expensive PG_TRY block by
using MemoryContextSetParent to reparent an initially-short-lived
context for the RLS data.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/21356c12-8917-8249-b35f-1c447231922b@postgrespro.ru
src/backend/commands/policy.c