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:08:15
Message-ID: 1302471.1773940095@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:
>   == 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-03-19 17:13:25 Re: pg_stat_replication.*_lag sometimes shows NULL during active replication
Previous Message Tom Lane 2026-03-19 17:02:18 Re: pg_plan_advice