From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ParseTzFile doesn't FreeFile on error |
Date: | 2022-05-31 18:21:28 |
Message-ID: | 239461.1654021288@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Mon, 30 May 2022 13:11:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
>> BTW, my first thought about it was "what if one of the callees throws
>> elog(ERROR), eg palloc out-of-memory"? But I think that's all right
>> since then we'll reach transaction abort cleanup, which won't whine
>> about open files. The problem is limited to the case where no error
>> gets thrown.
> Right. This "issue" is not a problem unless the caller continues
> without throwing an exception after the function errors out, which is
> not done by the current code.
Actually the problem *is* reachable, if you intentionally break the
already-active timezone abbreviation file: newly started sessions
produce file-leak warnings after failing to apply the setting.
I concede that's not a likely scenario, but that's why I think it's
worth fixing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-05-31 18:40:43 | Re: Prevent writes on large objects in read-only transactions |
Previous Message | Alvaro Herrera | 2022-05-31 18:15:14 | Re: PostgreSQL Limits: maximum number of columns in SELECT result |