SEO

Back in 2003 Bruce Momjian proposed adding a flag (-I) to psql to force
it into "interactive" mode. (See
http://archives.postgresql.org/pgsql...1/msg00013.php for
the thread.) The proposal was rejected because there was no proven need
for it at that time. I'd like to raise this proposal again, since I
think in our situation, this is the only fix for our problem.

Our environment is as follows:
* A large number of PostgreSQL 7.4 servers running on a variety of SuSE
Linux (9.0 - 9.3) servers
* A growing number of PostgreSQL 8.0.3 servers running on Windows Server
2003 servers. (We are running the native Win32 version of PostgreSQL,
not the Cygwin version.)

The servers are all located in remote offices. Maintenance is done
remotely via SSH to a "local" bash command prompt where we use the
command line tools: psql, pg_dump, etc. On Linux we use the native
sshd; on Windows we use Cygwin to get bash, sshd, cron, etc. On Linux
this works fine; on Windows, however, psql thinks it is not in an
interactive console so we get no prompts, no line editing, no history,
very little cursor control, etc. (I see that the missing autocomplete
feature is a readline issue, but that's a topic for another posting.)
This makes remote maintenance on the Windows servers much more difficult
than it otherwise could be.

The issue appears to be due to isatty() returning false in the Windows
Cygwin environment. From other research around the web, it appears that
if the app is "Cygwin-aware" is knows to override this check (or allow
manual override) or try to do further testing, but in this case, since
we are using the native Win32 version of PostgreSQL, psql doesn't do any
additional testing.

Also, even in the local console on Windows, running rxvt -- our
preferred terminal in Windows (since it lets us make our Windows command
line act just like our Linux command line <grin>) -- causes psql to
think that there is no terminal. (Our first encounter of this "no
terminal" problem was in trying to run psql via a local bash shell via
rxvt, and originally we thought that psql was hanging. Given our
reliance on psql for remote maintenance, this would have prevented our
rolling out a Windows version of PostgreSQL. It was only after too much
time looking at it with some low-level tools that we stumbled across the
fact that psql was simply silently waiting at a command prompt rather
than being hung. However, from other posts in these lists [e.g.:
http://archives.postgresql.org/pgsql...7/msg00369.php ] it
appears that other people also thought psql was hanging when it was run
from a terminal program, so I suppose I shouldn't feel too bad...)

Bruce's proposal and suggested code simply added a new "-I" flag to
force psql into "interactive mode" (by simply setting "pset.notty = 0").
From everything I can find (including reading through the Cygwin code,
ssh and sshd man pages and code, psql code, testing various modes of
running the sshd service in Windows, changing Windows profile account
permissions, etc.), adding this flag seems to be the only viable option
(other than writing a replacement for psql for our Windows servers,
something I'd prefer to not do). While I can obviously add this patch
myself and build and maintain a custom version of psql for our own use,
since there now is a true native version of PostgreSQL for Windows, I
think we will see a growing list of people supporting mixed environments
just like ours, and bumping into this exact same problem.

Thoughts?

- Bill

Bill Bartlett
meridianEMR, Inc.
http://www.meridianemr.com


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

I haven't seen any replies to this, so I guess you are left with either
hacking psql yourself or getting Cygwin folks to fix it. Sorry.

---------------------------------------------------------------------------

Bill Bartlett wrote:
> Back in 2003 Bruce Momjian proposed adding a flag (-I) to psql to force
> it into "interactive" mode. (See
> http://archives.postgresql.org/pgsql...1/msg00013.php for
> the thread.) The proposal was rejected because there was no proven need
> for it at that time. I'd like to raise this proposal again, since I
> think in our situation, this is the only fix for our problem.
>
> Our environment is as follows:
> * A large number of PostgreSQL 7.4 servers running on a variety of SuSE
> Linux (9.0 - 9.3) servers
> * A growing number of PostgreSQL 8.0.3 servers running on Windows Server
> 2003 servers. (We are running the native Win32 version of PostgreSQL,
> not the Cygwin version.)
>
> The servers are all located in remote offices. Maintenance is done
> remotely via SSH to a "local" bash command prompt where we use the
> command line tools: psql, pg_dump, etc. On Linux we use the native
> sshd; on Windows we use Cygwin to get bash, sshd, cron, etc. On Linux
> this works fine; on Windows, however, psql thinks it is not in an
> interactive console so we get no prompts, no line editing, no history,
> very little cursor control, etc. (I see that the missing autocomplete
> feature is a readline issue, but that's a topic for another posting.)
> This makes remote maintenance on the Windows servers much more difficult
> than it otherwise could be.
>
> The issue appears to be due to isatty() returning false in the Windows
> Cygwin environment. From other research around the web, it appears that
> if the app is "Cygwin-aware" is knows to override this check (or allow
> manual override) or try to do further testing, but in this case, since
> we are using the native Win32 version of PostgreSQL, psql doesn't do any
> additional testing.
>
> Also, even in the local console on Windows, running rxvt -- our
> preferred terminal in Windows (since it lets us make our Windows command
> line act just like our Linux command line <grin>) -- causes psql to
> think that there is no terminal. (Our first encounter of this "no
> terminal" problem was in trying to run psql via a local bash shell via
> rxvt, and originally we thought that psql was hanging. Given our
> reliance on psql for remote maintenance, this would have prevented our
> rolling out a Windows version of PostgreSQL. It was only after too much
> time looking at it with some low-level tools that we stumbled across the
> fact that psql was simply silently waiting at a command prompt rather
> than being hung. However, from other posts in these lists [e.g.:
> http://archives.postgresql.org/pgsql...7/msg00369.php ] it
> appears that other people also thought psql was hanging when it was run
> from a terminal program, so I suppose I shouldn't feel too bad...)
>
> Bruce's proposal and suggested code simply added a new "-I" flag to
> force psql into "interactive mode" (by simply setting "pset.notty = 0").
> >From everything I can find (including reading through the Cygwin code,
> ssh and sshd man pages and code, psql code, testing various modes of
> running the sshd service in Windows, changing Windows profile account
> permissions, etc.), adding this flag seems to be the only viable option
> (other than writing a replacement for psql for our Windows servers,
> something I'd prefer to not do). While I can obviously add this patch
> myself and build and maintain a custom version of psql for our own use,
> since there now is a true native version of PostgreSQL for Windows, I
> think we will see a growing list of people supporting mixed environments
> just like ours, and bumping into this exact same problem.
>
> Thoughts?
>
> - Bill
>
> Bill Bartlett
> meridianEMR, Inc.
> http://www.meridianemr.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Oct 13, 2005, at 4:42 PM, Bruce Momjian wrote:

> I haven't seen any replies to this, so I guess you are left with
> either
> hacking psql yourself or getting Cygwin folks to fix it. Sorry.

I have asked for this also. It would make it much easier to control
psql from other applications.

http://archives.postgresql.org/pgsql...04/threads.php

It seems pretty simple and non-invasive. I don't recall seeing the
reasons against doing it.



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

John DeSoi wrote:
>
> On Oct 13, 2005, at 4:42 PM, Bruce Momjian wrote:
>
> > I haven't seen any replies to this, so I guess you are left with
> > either
> > hacking psql yourself or getting Cygwin folks to fix it. Sorry.
>
> I have asked for this also. It would make it much easier to control
> psql from other applications.
>
> http://archives.postgresql.org/pgsql...04/threads.php
>
> It seems pretty simple and non-invasive. I don't recall seeing the
> reasons against doing it.

We need a large number of users who need something before we add it. If
we didn't we would have a mess of options.

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

>>http://archives.postgresql.org/pgsql...04/threads.php
>>
>>It seems pretty simple and non-invasive. I don't recall seeing the
>>reasons against doing it.
>>
>>
>
>We need a large number of users who need something before we add it. If
>we didn't we would have a mess of options.
>
>
The need seems like the exception rather than the norm. The posts that I
see are people
trying to use Unix tools, in Windows. I am not talking about the use of
psql, rather things
like the use of Cygwin and rxvt. Although it is nice when we can do
that, it should
be consider unsupported.

If you really want the environment, use RDP, VNC, or Citrix and start a
shell as normal.
Alternatively just use PostgreSQL with SSL and then connect from a
remote psql terminal.

Sincerely,

Joshua D. Drake





--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

What I couldn't work out was why the original requester didn't use the
Cygwin psql client, which should work just fine, instead of trying to use
the native client which we know has serious limitations.

cheers

andrew

Joshua D. Drake said:
>
>>>http://archives.postgresql.org/pgsql...04/threads.php
>>>
>>>It seems pretty simple and non-invasive. I don't recall seeing the
>>>reasons against doing it.
>>>
>>>
>>
>>We need a large number of users who need something before we add it.
>>If we didn't we would have a mess of options.
>>
>>
> The need seems like the exception rather than the norm. The posts that
> I see are people
> trying to use Unix tools, in Windows. I am not talking about the use of
> psql, rather things
> like the use of Cygwin and rxvt. Although it is nice when we can do
> that, it should
> be consider unsupported.
>
> If you really want the environment, use RDP, VNC, or Citrix and start a
> shell as normal.
> Alternatively just use PostgreSQL with SSL and then connect from a
> remote psql terminal.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
>
>
> --
> Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
> PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
> Managed Services, Shared and Dedicated Hosting
> Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
>
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 9: In versions below 8.0, the
> planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq