Re: ParseTzFile doesn't FreeFile on error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-05-30T17:11:04Z
Lists: pgsql-hackers
Attachments
- 0002-Fix-ParseTzFile-to-call-FreeFile-on-error.patch (text/x-diff) patch 0002
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes: > The cause is ParseTzFile() returns leaving an open file descriptor > unfreed in some error cases. > This happens only in a special case when the errors are ignored, but > in principle the file descriptor should be released before exiting the > function. > I'm not sure it's worth fixing but the attached fixes that. I agree this is worth fixing, but adding all these gotos seems a bit inelegant. What do you think of the attached version? 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. regards, tom lane
Commits
-
Ensure ParseTzFile() closes the input file after failing.
- c73748b68a0e 13.8 landed
- c47a558528dd 14.4 landed
- ae758e603d5c 11.17 landed
- a3faebd6a58a 12.12 landed
- 2114910cae6a 10.22 landed
- 16c80e7d0cda 15.0 landed