Re: get_controlfile() can leak fds in the backend

From: Andres Freund <andres(at)anarazel(dot)de>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: get_controlfile() can leak fds in the backend
Date: 2019-02-28 21:07:23
Message-ID: 20190228210723.qmjuh2mrifcb37wb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-02-28 09:54:48 +0100, Fabien COELHO wrote:
> > If we were to want to do more here, ISTM the right approach would use
> > the postmaster pid file, not the control file.
>
> ISTM that this just means re-inventing a manual poor-featured
> race-condition-prone lock API around another file, which seems to be created
> more or less only by "pg_ctl", while some other commands use the control
> file (eg pg_rewind, AFAICS).

Huh? Postmaster.pid is written by the backend, pg_ctl just checks it to
see if the backend has finished starting up etc. It's precisely what the
backend uses to prevent two postmasters to start etc. It's also what say
pg_resetwal checks to protect against a concurrently running lcuster
(albeit in a racy way). If we want to make things more bulletproof,
that's the place. The control file is constantly written to, sometimes
by different processes, it'd just not be a good file for such lockout
mechanisms.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2019-02-28 21:09:32 Re: get_controlfile() can leak fds in the backend
Previous Message Thomas Munro 2019-02-28 20:48:33 Re: Drop type "smgr"?