On 2023-05-17 We 17:55, Andres Freund wrote:
Hi,
On May 17, 2023 2:51:41 PM PDT, Andrew Dunstan wrote:
On 2023-05-16 Tu 17:52, Andres Freund wrote:
I suppose the alternative would be to change the way the buildfarm calls
pg_ctl stop. Do you have a concrete suggestion for that?
The easiest f
Hi,
On May 17, 2023 2:51:41 PM PDT, Andrew Dunstan wrote:
>
>On 2023-05-16 Tu 17:52, Andres Freund wrote:
>>
>>> I suppose the alternative would be to change the way the buildfarm calls
>>> pg_ctl stop. Do you have a concrete suggestion for that?
>> The easiest fix is to redirect stdin to /dev/
On 2023-05-16 Tu 17:52, Andres Freund wrote:
I suppose the alternative would be to change the way the buildfarm calls
pg_ctl stop. Do you have a concrete suggestion for that?
The easiest fix is to redirect stdin to /dev/null (or some file, if that's
easier to do portably) - that should fix th
Hi,
On 2023-05-16 08:55:20 -0400, Andrew Dunstan wrote:
> I don't know where this all leaves us. It's still more than odd that the
> start works fine and the stop doesn't.
>From what I understand it's just a question of starting another shell, with
some redirection, after having previously starte
On 2023-05-15 Mo 19:43, Andres Freund wrote:
Hi,
On 2023-05-15 15:30:28 -0700, Andres Freund wrote:
As soon as either the pg_ctl for the start, or the whole bash invocation, has
stdin redirected, the problem vanishes.
For a moment I thought this could be related to InheritStdHandles() - but n
Hi,
On 2023-05-15 15:30:28 -0700, Andres Freund wrote:
> As soon as either the pg_ctl for the start, or the whole bash invocation, has
> stdin redirected, the problem vanishes.
For a moment I thought this could be related to InheritStdHandles() - but no,
it doesn't make a difference.
There's loa
Hi,
On 2023-05-15 13:13:26 -0700, Andres Freund wrote:
> It wouldn't really - the echo $? inside the system() would report the
> error. Which it doesn't - note the "0" in the second output.
Ah. Interesting. Part of the issue is perl (or msys?) swalling some error
details.
I could see more detail
Hi,
On 2023-05-15 16:01:39 -0400, Andrew Dunstan wrote:
> On 2023-05-15 Mo 15:38, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> > > If you want to play I can arrange access.
> > Andrew did - thanks!
> >
> >
> > A first observeration is that making th
On 2023-05-15 Mo 15:38, Andres Freund wrote:
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
If you want to play I can arrange access.
Andrew did - thanks!
A first observeration is that making the shell command slightly more
complicated, by echoing $? after pg_ctl, prevents the erro
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> If you want to play I can arrange access.
Andrew did - thanks!
A first observeration is that making the shell command slightly more
complicated, by echoing $? after pg_ctl, prevents the error:
/usr/bin/perl -e 'system(qq{"bin/pg_ctl" -D
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> On 2023-05-04 Th 19:54, Andres Freund wrote:
> > Hm. I can't reproduce this in my test win10 VM, unfortunately. What OS / OS
> > version is the host? Any chance to get systeminfo.exe output or something
> > like
> > that?
>
>
> Its a Win
On 2023-05-04 Th 19:54, Andres Freund wrote:
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
> > > buildfarm support for meson:
> > >
> > > Here's a simpl
On 2023-05-03 We 14:26, Andres Freund wrote:
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support
On 2023-05-03 We 09:20, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for meson:
Here's a simple illustration of the proble
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
> > > buildfarm support for meson:
> > >
> > >
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for meson:
Here's a simple illustration of the problem. If I do the identical test with
a non-meson bu
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> Still running into this, and I am rather stumped. This is a blocker for
> buildfarm support for meson:
>
> Here's a simple illustration of the problem. If I do the identical test with
> a non-meson build there is no problem:
This happens
On 2023-04-26 We 11:30, Tom Lane wrote:
Andrew Dunstan writes:
If I redirect the output to a file (which is what the buildfarm client
actually does), it seems like it completes successfully, but I still get
a non-zero exit:
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/H
Andrew Dunstan writes:
> If I redirect the output to a file (which is what the buildfarm client
> actually does), it seems like it completes successfully, but I still get
> a non-zero exit:
> pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
> $ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-4
On 2023-04-26 We 10:58, Tom Lane wrote:
I wrote:
Looking at the pg_ctl source code, the only way I can explain that
printout is that do_stop called wait_for_postmaster_stop which,
after one or more loops, exited via one of its exit() calls.
Ah, a little too hasty there: it's get_pgpid() that h
I wrote:
> Looking at the pg_ctl source code, the only way I can explain that
> printout is that do_stop called wait_for_postmaster_stop which,
> after one or more loops, exited via one of its exit() calls.
Ah, a little too hasty there: it's get_pgpid() that has to be
reaching an exit().
Andrew Dunstan writes:
>> For some reason which makes no sense to me the buildfarm animal fails
>> at the first Stop-Db step. The DB is actually stopped, but pg_ctl
>> returns a non-zero status. The thing that's really odd is that meson
>> isn't at all involved in this step. But it's happened e
23 matches
Mail list logo
