aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/collationcmds.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-03-08 16:32:29 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-03-08 16:32:29 -0500
commit6c20bdb2a279086777a3595ab00bcf14671fc5a1 (patch)
treee3072396155102c9b7b8c8c30962dc5cc2f4d565 /src/backend/commands/collationcmds.c
parent8a812e5106c5db50039336288d376a188844e2cc (diff)
downloadpostgresql-6c20bdb2a279086777a3595ab00bcf14671fc5a1.tar.gz
postgresql-6c20bdb2a279086777a3595ab00bcf14671fc5a1.zip
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.
Diffstat (limited to 'src/backend/commands/collationcmds.c')
0 files changed, 0 insertions, 0 deletions