From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Further tweak memory management for regex DFAs. |
Date: | 2021-03-08 21:32:52 |
Message-ID: | E1lJNUi-0003Tn-Fz@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Further tweak memory management for regex DFAs.
Coverity is still unhappy after commit 190c79884, and after looking
closer I think it might be onto something. The callers of newdfa()
typically drop out if v->err has been set nonzero, which newdfa()
is faithfully doing if it fails. However, what if v->err was already
nonzero before we entered newdfa()? Then newdfa() could succeed and
the caller would promptly leak its result.
I don't think this scenario can actually happen, but the predicate
"v->err is always zero when newdfa() is called" seems difficult to be
entirely sure of; there's a good deal of code that potentially could
get that wrong.
It seems better to adjust the callers to directly check for a null
result instead of relying on ISERR() tests. This is slightly cheaper
than the previous coding anyway.
Lacking evidence that there's any real bug, no back-patch.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/6c20bdb2a279086777a3595ab00bcf14671fc5a1
Modified Files
--------------
src/backend/regex/rege_dfa.c | 2 ++
src/backend/regex/regexec.c | 18 ++++++++----------
2 files changed, 10 insertions(+), 10 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-08 23:22:11 | pgsql: Validate the OID argument of pg_import_system_collations(). |
Previous Message | Amit Kapila | 2021-03-08 02:36:47 | pgsql: Track replication origin progress for rollbacks. |