public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jianghua Yang <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
Date: Thu, 19 Mar 2026 10:19:10 -0700
Message-ID: <CAAZLFmR-S3tyN2xC1K0jZ3T13JZD=_36mYu+0WKCKs1wEROuLw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[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
>

view thread (2+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
  In-Reply-To: <CAAZLFmR-S3tyN2xC1K0jZ3T13JZD=_36mYu+0WKCKs1wEROuLw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox