public inbox for [email protected]
help / color / mirror / Atom feedRe: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
2+ messages / 1 participants
[nested] [flat]
* Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
@ 2026-03-19 17:19 Jianghua Yang <[email protected]>
2026-03-19 18:28 ` Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails Jianghua Yang <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Jianghua Yang @ 2026-03-19 17:19 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]
You're correct. All callers invoke pg_fatal() on failure, so the
process exits immediately and the OS reclaims the fd. There is no
live bug worth back-patching on those grounds.
That said, the patch does fix a real diagnostic problem. In the
original code, when dup() fails with EMFILE, the -1 return value is
passed directly to fdopen(), which fails with EBADF. The user sees:
pg_dump: error: could not open output file: Bad file descriptor
which is misleading -- the actual cause is fd exhaustion, not a bad
descriptor. With the patch, errno is preserved correctly, so the
message becomes:
pg_dump: error: could not open output file: Too many open files
which gives the user actionable information.
I'm happy to limit this to HEAD only if back-patching is not
warranted.
Regards,
Jianghua Yang
Tom Lane <[email protected]> 于2026年3月19日周四 10:08写道：
> Jianghua Yang <[email protected]> writes:
> > == The Bug ==
>
> > All four compression open functions use this pattern when an existing
> > file descriptor is passed in:
>
> > if (fd >= 0)
> > fp = fdopen(dup(fd), mode); /* or gzdopen() */
>
> > if (fp == NULL)
> > return false; /* dup'd fd is leaked here */
>
> > The problem is that dup(fd) and fdopen()/gzdopen() are two separate
> > steps, and their failure modes must be handled independently:
>
> Hmm. You're right that we could leak the dup'd FD, but would it matter?
> I'm pretty sure all these programs will just exit immediately on
> failure.
>
> I'm not averse to improving the code, but I'm not sure there is
> a live bug worth back-patching.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
2026-03-19 17:19 Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails Jianghua Yang <[email protected]>
@ 2026-03-19 18:28 ` Jianghua Yang <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Jianghua Yang @ 2026-03-19 18:28 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]
Thanks for pushing and for the extra scan.
Regards,
Jianghua Yang
Tom Lane <[email protected]> 于2026年3月19日周四 11:26写道：
> I wrote:
> > Fair point. Still, this is such an unlikely edge-case that
> > I don't think it's worth a back-patch. Let's just do HEAD.
>
> Pushed. I also looked around for other instances of the same
> pattern, and couldn't find any.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-03-19 18:28 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-19 17:19 Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails Jianghua Yang <[email protected]>
2026-03-19 18:28 ` Jianghua Yang <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox