Re: get_controlfile() can leak fds in the backend

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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
Date: 2019-03-01 01:19:29
Message-ID: 20190301011929.fjtlr3kkqhgs2son@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-03-01 10:11:53 +0900, Michael Paquier wrote:
> 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.

I think putting this into the control file is a seriously bad
idea. Postmaster interlocks against other postmasters running via
postmaster.pid. Having a second interlock mechanism, in a different
file, doesn't make any sort of sense. Nor does it seem sane to have
external tool write over data as INTENSELY critical as the control file,
when they then have to understand CRCs etc.

> 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.

I don't know what that means, given you replied to the above in this
thread?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2019-03-01 01:19:38 Re: SQL/JSON: JSON_TABLE
Previous Message Nikita Glukhov 2019-03-01 01:14:09 Re: SQL/JSON: functions