|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Thu, Feb 28, 2019 at 01:07:23PM -0800, Andres Freund wrote:
> 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
Hijacking more my own thread... I can do that, right? Or not.
One thing is that we don't protect a data folder to be started when it
is in the process of being treated by an external tool, like
pg_rewind, or pg_checksums. So having an extra flag in the control
file, which can be used by external tools to tell that the data folder
is being treated for something does not sound that crazy to me.
Having a tool write a fake postmaster.pid for this kind of task does
not sound right from a correctness point of view, because the instance
is not started.
And a lock API won't protect much if the host is unplugged as well if
its state is made durable...
Let's keep the discussions where they are by the way. Joe has just
closed the report of this thread with 4598a99, so I am moving on to
the correct places.
My apologies for the digressions.
|Next Message||Nikita Glukhov||2019-03-01 01:14:09||Re: SQL/JSON: functions|
|Previous Message||Michael Paquier||2019-03-01 01:00:42||Re: get_controlfile() can leak fds in the backend|