Michael Paquier writes:
> On Tue, Oct 13, 2015 at 7:41 AM, Tom Lane wrote:
>> I'm not sure if this will completely fix our problems with "pg_ctl start"
>> related buildfarm failures on very slow critters. It does get rid of the
>> hard wired
On Tue, Oct 13, 2015 at 7:41 AM, Tom Lane wrote:
> So there's still something to be desired on Windows; but it's still
> better than before in that we can reliably detect child process exit
> instead of having to use the five-second heuristic. And of course on
> Unix this is
Michael Paquier writes:
>> On Wed, Oct 7, 2015 at 11:52 PM, Tom Lane wrote:
>>> I think there is still room to salvage something without fully rewriting
>>> the postmaster invocation logic to avoid using CMD, because it's still
>>> true that
Alvaro Herrera writes:
> I wonder if you are interested in rewriting this whole thing to not use
> cmd.exe at all, which as I understand is just about output redirection.
FWIW, I have little interest in going there, because I'm afraid that
getting it to be
Michael Paquier wrote:
> > That would be WaitForSingleObject(handle, ms_timeout) ==
> > WAIT_OBJECT_0, no? The handle should be picked up from
> > CreateRestrictedProcess, and I think that CloseHandle should not be
> > called on pi.hProcess if we are going to wait for it afterwards.
> >
On Wed, Oct 7, 2015 at 11:52 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>>> So the attached modified patch adjusts the PID-match logic and some
>>> comments, but is otherwise what I posted
On Thu, Oct 8, 2015 at 3:09 PM, Michael Paquier
wrote:
> On Wed, Oct 7, 2015 at 11:52 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
So the attached modified patch
On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
> So the attached modified patch adjusts the PID-match logic and some
> comments, but is otherwise what I posted before. I believe that this
> might actually work on Windows, but I have no way to test it. Someone
> please try that? (Don't forget
Michael Paquier writes:
> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before. I believe that this
>> might actually work on Windows, but I have no
Michael Paquier writes:
> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before. I believe that this
>> might actually work on Windows, but I have no
On Wed, Oct 7, 2015 at 6:44 AM, Tom Lane wrote:
> I wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before. I believe that this
>> might actually work on Windows, but I have no way to test it. Someone
I wrote:
> So the attached modified patch adjusts the PID-match logic and some
> comments, but is otherwise what I posted before. I believe that this
> might actually work on Windows, but I have no way to test it. Someone
> please try that? (Don't forget to test the service-start path, too.)
On Wed, Oct 7, 2015 at 7:05 AM, Michael Paquier
wrote:
> On Wed, Oct 7, 2015 at 6:44 AM, Tom Lane wrote:
>> I wrote:
>>> So the attached modified patch adjusts the PID-match logic and some
>>> comments, but is otherwise what I posted before. I
I wrote:
> Attached is a draft patch for this. I think it's fine for Unix (unless
> someone wants to object to relying on "/bin/sh -c"), but I have no idea
> whether it works for Windows. The main risk is that if CMD.EXE runs
> the postmaster as a subprocess rather than overlaying itself a la
On Fri, Sep 04, 2015 at 10:54:51PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Sep 03, 2015 at 03:31:06PM -0400, Tom Lane wrote:
> >>> This is the first time I've seen an indication that the
> >>> start_postmaster change mentioned in the comment is actually
On Sat, Sep 05, 2015 at 10:22:59PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > kill() adds nothing when dealing with a pg_ctl child. waitpid() is enough.
>
> The kill() coding works on Windows (I believe); waitpid() not so much.
Windows has the concept under a different
Noah Misch writes:
> On Sat, Sep 05, 2015 at 10:22:59PM -0400, Tom Lane wrote:
>> The kill() coding works on Windows (I believe); waitpid() not so much.
> Windows has the concept under a different name. See postmaster.c.
Well, if someone else wants to code and test that,
Noah Misch writes:
> kill() adds nothing when dealing with a pg_ctl child. waitpid() is enough.
The kill() coding works on Windows (I believe); waitpid() not so much.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Noah Misch writes:
> On Thu, Sep 03, 2015 at 03:31:06PM -0400, Tom Lane wrote:
>>> This is the first time I've seen an indication that the
>>> start_postmaster change mentioned in the comment is actually important
>>> for production use, rather than just being cleanup.
> I
On Thu, Sep 03, 2015 at 03:31:06PM -0400, Tom Lane wrote:
> I wrote:
> > This is the first time I've seen an indication that the
> > start_postmaster change mentioned in the comment is actually important
> > for production use, rather than just being cleanup.
I scratched my head awhile without
I wrote:
> Andres Freund writes:
>> I'don't like adding a couple seconds of test runtime for the benefit of
>> very slow platforms.
> Me either. This is the first time I've seen an indication that the
> start_postmaster change mentioned in the comment is actually important
>
Andrew Dunstan writes:
> There is no equivalent of execl, nor a cmd.exe exquivalent of the
> shell's exec. But surely the equivalent of the fork/execl you're doing
> here would be a simple CreateProcess(). I don't see why you need a shell
> in the middle on Windows at all.
Tom Lane wrote:
> Andrew Dunstan writes:
> > There is no equivalent of execl, nor a cmd.exe exquivalent of the
> > shell's exec. But surely the equivalent of the fork/execl you're doing
> > here would be a simple CreateProcess(). I don't see why you need a shell
> > in the
On 09/03/2015 03:31 PM, Tom Lane wrote:
I wrote:
Andres Freund writes:
I'don't like adding a couple seconds of test runtime for the benefit of
very slow platforms.
Me either. This is the first time I've seen an indication that the
start_postmaster change mentioned in
My AIX buildfarm members have failed the BinInstallCheck step on and off since
inception. It became more frequent when I added animals sungazer and tern
alongside the older hornet and mandrill. The animals share a machine with
each other and with dozens of other developers. I setpriority() the
On 2015-09-03 02:25:00 -0400, Noah Misch wrote:
> --- a/src/bin/pg_ctl/t/001_start_stop.pl
> +++ b/src/bin/pg_ctl/t/001_start_stop.pl
> @@ -35,6 +35,7 @@ close CONF;
> command_ok([ 'pg_ctl', 'start', '-D', "$tempdir/data", '-w' ],
> 'pg_ctl start -w');
> -command_ok([ 'pg_ctl', 'start',
Andres Freund writes:
> On 2015-09-03 02:25:00 -0400, Noah Misch wrote:
>> --- a/src/bin/pg_ctl/t/001_start_stop.pl
>> +++ b/src/bin/pg_ctl/t/001_start_stop.pl
>> @@ -35,6 +35,7 @@ close CONF;
>> command_ok([ 'pg_ctl', 'start', '-D', "$tempdir/data", '-w' ],
>> 'pg_ctl start
27 matches
Mail list logo