On 30/12/2018 22:56, Tom Lane wrote:
This comment needs copy-editing:
+ * If the user hits interrupts the startup (e.g. with CTRL-C), we'd
Looks good otherwise.
Thanks, fixed that, and pushed.
- Heikki
Heikki Linnakangas writes:
> Here's a patch to implement that. Seems to work. There is a small window
> between launching postmaster and installing the signal handler, though,
> where CTRL-C on pg_ctl will not abort the server launch. I think that's
> acceptable.
Hm ... you could partially
On 30/12/2018 21:59, Heikki Linnakangas wrote:
On 28/12/2018 22:13, Tom Lane wrote:
Heikki Linnakangas writes:
Another idea would be to call setsid() in pg_ctl, after forking
postmaster, like in Paul's original patch. That solves 1. and 2. To
still do 3., add a signal handler for SIGINT in
Heikki Linnakangas writes:
> We talked about adding a flag to postmaster, to tell it to call
> setsid(). But I'm not sure what would be the appropriate time to do it.
Yeah, there's no ideal time in the postmaster.
> Another idea would be to call setsid() in pg_ctl, after forking
>
On 30/09/2018 15:47, Michael Paquier wrote:
On Thu, Sep 13, 2018 at 12:24:38PM -0700, Andres Freund wrote:
On 2018-09-13 15:27:58 +0800, Paul Guo wrote:
From the respective of users instead of developers, I think for such
important
service, tty should be dissociated, i.e. postmaster should be
On Thu, Sep 13, 2018 at 12:24:38PM -0700, Andres Freund wrote:
> On 2018-09-13 15:27:58 +0800, Paul Guo wrote:
>> From the respective of users instead of developers, I think for such
>> important
>> service, tty should be dissociated, i.e. postmaster should be daemonized by
>> default (and even
Hi,
On 2018-09-13 15:27:58 +0800, Paul Guo wrote:
> From the respective of users instead of developers, I think for such
> important
> service, tty should be dissociated, i.e. postmaster should be daemonized by
> default (and even should have default log filename?) or be setsid()-ed at
> least.
On Thu, Sep 13, 2018 at 8:20 AM, Michael Paquier
wrote:
> On Wed, Sep 12, 2018 at 03:55:00PM -0400, Tom Lane wrote:
> > Although pg_ctl could sneak it in between forking and execing, it seems
> > like it'd be cleaner to have the postmaster proper do it in response to
> > a switch that pg_ctl
On Wed, Sep 12, 2018 at 03:55:00PM -0400, Tom Lane wrote:
> Although pg_ctl could sneak it in between forking and execing, it seems
> like it'd be cleaner to have the postmaster proper do it in response to
> a switch that pg_ctl passes it. That avoids depending on the fork/exec
> separation, and
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Hmph. Can't we just ignore that error?
> If you ignore the error from setsid(), then you're still a process group
> leader (as you would be after running setsid()), but you're still
> attached to whatever controlling terminal (if any)
> "Tom" == Tom Lane writes:
>> The tricky part about doing setsid() is this: you're not allowed to
>> do it if you're already a process group leader. silent_mode worked
>> by having postmaster do another fork, exit in the parent, and do
>> setsid() in the child.
Tom> Hmph. Can't we
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> We'd likely need a switch to control that. If memory serves, there
> Tom> used to be such a switch, but we got rid of the postmaster's
> Tom> setsid call and the switch too. We probably should dig in the
> Tom> archives and review the
> "Tom" == Tom Lane writes:
Tom> BTW, just thinking outside the box a bit --- perhaps the ideal
Tom> behavior to address Michael's use-case would be to have the
Tom> postmaster itself do setsid(), but not until it reaches the state
Tom> of being ready to accept client connections.
Tom>
I wrote:
> Michael Paquier writes:
>> Hmm. This patch breaks a feature of pg_ctl that I am really fond of for
>> development. When starting a node which enters in recovery, I sometimes
>> use Ctrl-C to stop pg_ctl, which automatically makes the started
>> Postgres instance to stop, and this
Michael Paquier writes:
> On Mon, Aug 06, 2018 at 12:11:26PM +0800, Paul Guo wrote:
>> Yes, if considering the case of starting postmaster manually, we can not
>> create
>> a new session in postmaster, so pg_ctl seems to be a good place for setsid()
>> call. Attached a newer patch. Thanks.
>
On Mon, Aug 06, 2018 at 12:11:26PM +0800, Paul Guo wrote:
> Yes, if considering the case of starting postmaster manually, we can not
> create
> a new session in postmaster, so pg_ctl seems to be a good place for setsid()
> call. Attached a newer patch. Thanks.
Hmm. This patch breaks a feature of
On Thu, Aug 2, 2018 at 10:30 PM, Tom Lane wrote:
> Paul Guo writes:
> > [ make the postmaster execute setsid() too ]
>
> I'm a bit skeptical of this proposal. Forcing the postmaster to
> dissociate from its controlling terminal is a good thing in some
> scenarios, but probably less good in
Paul Guo writes:
> [ make the postmaster execute setsid() too ]
I'm a bit skeptical of this proposal. Forcing the postmaster to
dissociate from its controlling terminal is a good thing in some
scenarios, but probably less good in others, and manual postmaster
starts are probably mostly in the
Hello,
Recently I encountered an issue during testing and rootcaused it as the
title mentioned.
postmaster children have done this (creating a new session) by calling
InitPostmasterChild(),
but postmaster itself does not. This could lead to some issues (e..g signal
handling). The test script
19 matches
Mail list logo
