Thread: pg_ctl strangeness under msys

I have seen some strange things using pg_ctl under MSys:

. "pg_ctl status" from the command line logs to the event log.
Apparently it thinks it's not on a tty. Works fine from Windows cmd prompt.
. this hangs: perl -e '@foo=`pg_ctl -w start`;'
  but this doesn't: perl -e 'system("pg_ctl -w start");'

Finding the problem with the last one has cost me hours in trying to get
the buildfarm to run.

Anyone have ideas about ways to fix? Or do we just note it and live with it?

cheers

andrew

> I have seen some strange things using pg_ctl under MSys:
>
> . "pg_ctl status" from the command line logs to the event log.
> Apparently it thinks it's not on a tty. Works fine from
> Windows cmd prompt.
> . this hangs: perl -e '@foo=`pg_ctl -w start`;'
>   but this doesn't: perl -e 'system("pg_ctl -w start");'
>
> Finding the problem with the last one has cost me hours in
> trying to get the buildfarm to run.
>
> Anyone have ideas about ways to fix? Or do we just note it
> and live with it?

As I'm sure you are already aware we've had a lot of problems with the
msys console. Buffernig and others. I think we at some point decided to
say that minor issues on the win32 consoles isn't really something we're
concerned about, people will run things from the cmd console in 99.9% of
all cases.

Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
and that one is clearly returning the wrong thing on msys. Not sure how
to code around that.

As for the perl command, what perl is this? ActiveState or MingW? Do you
get the same problem if you run it in the cmd.exe environment, or only
in the msys console?

//Magnus

Magnus Hagander wrote:

>>I have seen some strange things using pg_ctl under MSys:
>>
>>. "pg_ctl status" from the command line logs to the event log.
>>Apparently it thinks it's not on a tty. Works fine from
>>Windows cmd prompt.
>>. this hangs: perl -e '@foo=`pg_ctl -w start`;'
>>  but this doesn't: perl -e 'system("pg_ctl -w start");'
>>
>>Finding the problem with the last one has cost me hours in
>>trying to get the buildfarm to run.
>>
>>Anyone have ideas about ways to fix? Or do we just note it
>>and live with it?
>>
>>
>
>As I'm sure you are already aware we've had a lot of problems with the
>msys console. Buffernig and others. I think we at some point decided to
>say that minor issues on the win32 consoles isn't really something we're
>concerned about, people will run things from the cmd console in 99.9% of
>all cases.
>
>Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
>and that one is clearly returning the wrong thing on msys. Not sure how
>to code around that.
>
>

The only way I can think of is an explicit flag that says "tell me on
the console". Probably not worth worrying about - just a fact to keep in
mind in case other people get confused as I did.

>As for the perl command, what perl is this? ActiveState or MingW? Do you
>get the same problem if you run it in the cmd.exe environment, or only
>in the msys console?
>
>
>

It's the perl from the MSys DTK.

This all came about from trying to get my buildfarm script (written in
perl) running on Windows. I have to use the MSys DTK perl for that
because it is the only one that understands MSys virtual paths - tried
ASPerl and Cygwin perl and it blew up both times. Complicating the
situation is the fact that the DTK perl apparently isn't selfhosted, so
installing needed CPAN modules on it is next to impossible. This means
that I'm actually going to have to use 2 different perl's for the
Windows buildfarm (!) - the DTK version for the build portions and one
of the others (I am testing using ASPerl) for the web transaction part
(which used LWP, MIME:Base64 and DIgest::SHA1). Add to that the fact
that the DTK perl doesn't even have Storable.pm and you will see how
ugly it gets. But it's still worth doing. :-) I haven't even looked yet
at adding in the extras (like SSL, plpython, pltcl, plperl).

Bottom line: these are problems that annoyed and frustrated me, but
won't affect ordinary users.

cheers

andrew

Magnus Hagander wrote:
> > I have seen some strange things using pg_ctl under MSys:
> >
> > . "pg_ctl status" from the command line logs to the event log.
> > Apparently it thinks it's not on a tty. Works fine from
> > Windows cmd prompt.
> > . this hangs: perl -e '@foo=`pg_ctl -w start`;'
> >   but this doesn't: perl -e 'system("pg_ctl -w start");'
> >
> > Finding the problem with the last one has cost me hours in
> > trying to get the buildfarm to run.
> >
> > Anyone have ideas about ways to fix? Or do we just note it
> > and live with it?
>
> As I'm sure you are already aware we've had a lot of problems with the
> msys console. Buffernig and others. I think we at some point decided to
> say that minor issues on the win32 consoles isn't really something we're
> concerned about, people will run things from the cmd console in 99.9% of
> all cases.
>
> Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
> and that one is clearly returning the wrong thing on msys. Not sure how
> to code around that.

We actually added the ability to turn the psql pager always on to fix a
problem with a Win32 user running psql inside some kind of application
(emacs?) where isatty returned the wrong value.  I don't see any clean
workaround here though.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Magnus Hagander wrote:
>
>
>>>I have seen some strange things using pg_ctl under MSys:
>>>
>>>. "pg_ctl status" from the command line logs to the event log.
>>>Apparently it thinks it's not on a tty. Works fine from
>>>Windows cmd prompt.
>>>. this hangs: perl -e '@foo=`pg_ctl -w start`;'
>>>  but this doesn't: perl -e 'system("pg_ctl -w start");'
>>>
>>>Finding the problem with the last one has cost me hours in
>>>trying to get the buildfarm to run.
>>>
>>>Anyone have ideas about ways to fix? Or do we just note it
>>>and live with it?
>>>
>>>
>>As I'm sure you are already aware we've had a lot of problems with the
>>msys console. Buffernig and others. I think we at some point decided to
>>say that minor issues on the win32 consoles isn't really something we're
>>concerned about, people will run things from the cmd console in 99.9% of
>>all cases.
>>
>>Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
>>and that one is clearly returning the wrong thing on msys. Not sure how
>>to code around that.
>>
>>
>
>We actually added the ability to turn the psql pager always on to fix a
>problem with a Win32 user running psql inside some kind of application
>(emacs?) where isatty returned the wrong value.  I don't see any clean
>workaround here though.
>
>

It might be useful to have such a switch on pg_ctl too ("Use
stdout/stderr even if you think it isn't a tty"). I can't see why it
couldn't be done. None of this is critical, it was just confusing and
time-consuming to find workarounds.

cheers

andrew

Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > I have seen some strange things using pg_ctl under MSys:
> > >
> > > . "pg_ctl status" from the command line logs to the event log.
> > > Apparently it thinks it's not on a tty. Works fine from
> > > Windows cmd prompt.
> > > . this hangs: perl -e '@foo=`pg_ctl -w start`;'
> > >   but this doesn't: perl -e 'system("pg_ctl -w start");'
> > >
> > > Finding the problem with the last one has cost me hours in
> > > trying to get the buildfarm to run.
> > >
> > > Anyone have ideas about ways to fix? Or do we just note it
> > > and live with it?
> >
> > As I'm sure you are already aware we've had a lot of problems with the
> > msys console. Buffernig and others. I think we at some point decided to
> > say that minor issues on the win32 consoles isn't really something we're
> > concerned about, people will run things from the cmd console in 99.9% of
> > all cases.
> >
> > Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
> > and that one is clearly returning the wrong thing on msys. Not sure how
> > to code around that.
>
> We actually added the ability to turn the psql pager always on to fix a
> problem with a Win32 user running psql inside some kind of application
> (emacs?) where isatty returned the wrong value.  I don't see any clean
> workaround here though.

Have you tried:

    pg_ctl start 2>/dev/tty

that would force stderr to go to the tty.  This might help because the
pg_ctl.c test is:

        if (!isatty(fileno(stderr)))    /* Running as a service */

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Bruce Momjian wrote:
>
>
>>Magnus Hagander wrote:
>>
>>
>>>>I have seen some strange things using pg_ctl under MSys:
>>>>
>>>>. "pg_ctl status" from the command line logs to the event log.
>>>>Apparently it thinks it's not on a tty. Works fine from
>>>>Windows cmd prompt.
>>>>. this hangs: perl -e '@foo=`pg_ctl -w start`;'
>>>>  but this doesn't: perl -e 'system("pg_ctl -w start");'
>>>>
>>>>Finding the problem with the last one has cost me hours in
>>>>trying to get the buildfarm to run.
>>>>
>>>>Anyone have ideas about ways to fix? Or do we just note it
>>>>and live with it?
>>>>
>>>>
>>>As I'm sure you are already aware we've had a lot of problems with the
>>>msys console. Buffernig and others. I think we at some point decided to
>>>say that minor issues on the win32 consoles isn't really something we're
>>>concerned about, people will run things from the cmd console in 99.9% of
>>>all cases.
>>>
>>>Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
>>>and that one is clearly returning the wrong thing on msys. Not sure how
>>>to code around that.
>>>
>>>
>>We actually added the ability to turn the psql pager always on to fix a
>>problem with a Win32 user running psql inside some kind of application
>>(emacs?) where isatty returned the wrong value.  I don't see any clean
>>workaround here though.
>>
>>
>
>Have you tried:
>
>    pg_ctl start 2>/dev/tty
>
>that would force stderr to go to the tty.  This might help because the
>pg_ctl.c test is:
>
>        if (!isatty(fileno(stderr)))    /* Running as a service */
>
>
>

This was about status, not start.

  pg_ctl status 2>/dev/tty

gives me the same thing as before. But only if the postmaster isn't
running - if it is running I get the status as expected, because then we
write to stdout rather than calling write_stderr() - I'm not sure I
understand why we do that.

cheers

andrew

Andrew Dunstan wrote:
> >Have you tried:
> >
> >    pg_ctl start 2>/dev/tty
> >
> >that would force stderr to go to the tty.  This might help because the
> >pg_ctl.c test is:
> >
> >        if (!isatty(fileno(stderr)))    /* Running as a service */
> >
> >  
> >
> 
> This was about status, not start.
> 
>   pg_ctl status 2>/dev/tty
> 
> gives me the same thing as before. But only if the postmaster isn't 
> running - if it is running I get the status as expected, because then we 
> write to stdout rather than calling write_stderr() - I'm not sure I 
> understand why we do that.

Yes, that is a bug that is fixed with the applied patch.  We should
alway print status to stdout, even stopped status.  We did that in 7.4
and should continue with that in 8.0.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: src/bin/pg_ctl/pg_ctl.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.43
diff -c -c -r1.43 pg_ctl.c
*** src/bin/pg_ctl/pg_ctl.c    27 Oct 2004 17:17:07 -0000    1.43
--- src/bin/pg_ctl/pg_ctl.c    27 Oct 2004 19:43:01 -0000
***************
*** 767,786 ****
      pid = get_pgpid();
      if (pid == 0)                /* no pid file */
      {
!         write_stderr(_("%s: neither postmaster nor postgres running\n"), progname);
          exit(1);
      }
      else if (pid < 0)            /* standalone backend */
      {
          pid = -pid;
!         fprintf(stdout, _("%s: a standalone backend \"postgres\" is running (PID: %ld)\n"), progname, pid);
      }
      else
      /* postmaster */
      {
          char      **optlines;
  
!         fprintf(stdout, _("%s: postmaster is running (PID: %ld)\n"), progname, pid);
  
          optlines = readfile(postopts_file);
          if (optlines != NULL)
--- 767,786 ----
      pid = get_pgpid();
      if (pid == 0)                /* no pid file */
      {
!         printf(_("%s: neither postmaster nor postgres running\n"), progname);
          exit(1);
      }
      else if (pid < 0)            /* standalone backend */
      {
          pid = -pid;
!         printf(_("%s: a standalone backend \"postgres\" is running (PID: %ld)\n"), progname, pid);
      }
      else
      /* postmaster */
      {
          char      **optlines;
  
!         printf(_("%s: postmaster is running (PID: %ld)\n"), progname, pid);
  
          optlines = readfile(postopts_file);
          if (optlines != NULL)