Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jianghua Yang <yjhjstz(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails
Date: 2026-03-19 17:35:34
Message-ID: 1305470.1773941734@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jianghua Yang <yjhjstz(at)gmail(dot)com> writes:
> 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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-03-19 17:36:29 Re: another autovacuum scheduling thread
Previous Message Amit Langote 2026-03-19 17:20:49 Re: generic plans and "initial" pruning