psql screen size

wstrzalka wrote:

I'm using psql mainly in putty window.

I have a problem while resizing the window.
When changing the window size (and those chars per row) psql output
becomes mess, the only rescue is to exit and run the psql again. It
looks like it's initializing the output params at startup and don't
refresh it in runtime.
Is there any way to deal with it? Or maybe some patch to psql could be
applied? If shell console or vi can work this way why not psql?

It appears to work fine for everyone else. You'll have to do some more
research and/or provide more details about the platform and package at
the other end of the putty connection.

On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote:

I'm using psql mainly in putty window.

it's pretty much always just worked with me. I'm using a very old
version of putty, but it all hangs together as well as anything else
does

When changing the window size (and those chars per row) psql output
becomes mess, the only rescue is to exit and run the psql again. It
looks like it's initializing the output params at startup and don't
refresh it in runtime.

Resizing the window when entering SQL works OK for me, but resizing when
inside my pager (normally the "less" utility, when you get more results
than will fit on the screen) causes psql to be confused when I return to
it.

Exactly the same bug occurred in various shells a while ago and was
fixed (I believe) by getting them to inquire about the screen dimensions
far more than they strictly ought to be doing. I'd also guess that psql
doesn't know or care about the screen size as it's all handled by the
"readline" library.

Sam

On 27 Paź, 13:16, s...@samason.me.uk (Sam Mason) wrote:

On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote:

I'm using psql mainly in putty window.

it's pretty much always just worked with me.  I'm using a very old
version of putty, but it all hangs together as well as anything else
does

When changing the window size (and those chars per row) psql output
becomes mess, the only rescue is to exit and run the psql again. It
looks like it's initializing the output params at startup and don't
refresh it in runtime.

Resizing the window when entering SQL works OK for me, but resizing when
inside my pager (normally the "less" utility, when you get more results
than will fit on the screen) causes psql to be confused when I return to
it.

Exactly the same bug occurred in various shells a while ago and was
fixed (I believe) by getting them to inquire about the screen dimensions
far more than they strictly ought to be doing.  I'd also guess that psql
doesn't know or care about the screen size as it's all handled by the
"readline" library.

  Sam

--
Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org)
To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general

Yes. This is exactly the case. When I browse large paged query result
and resize during that, the screen is messed up.

wstrzalka <wstrzalka@gmail.com> writes:

On 27 Paź, 13:16, s...@samason.me.uk (Sam Mason) wrote:

On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote:

When changing the window size (and those chars per row) psql output
becomes mess, the only rescue is to exit and run the psql again. It
looks like it's initializing the output params at startup and don't
refresh it in runtime.

At least in CVS HEAD it checks before every query output.

However...

Resizing the window when entering SQL works OK for me, but resizing when
inside my pager (normally the "less" utility, when you get more results
than will fit on the screen) causes psql to be confused when I return to
it.

Yes. This is exactly the case. When I browse large paged query result
and resize during that, the screen is messed up.

Could you define "messed up"?

What I see is that the query output is formatted correctly but readline still
thinks the screen is the old size. (This is in CVS HEAD -- this code was
definitely different in 8.3 and before so the behaviour may be different).

Perhaps we need to tell readline whenever we run a subprocess and it may have
missed screen resize signals.

It's easy enough to work around, just resize the window again a little bit
once you're at the prompt. Readline notices that and adjusts.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

Gregory Stark <stark@enterprisedb.com> writes:

Could you define "messed up"?

What I see is that the query output is formatted correctly but readline still
thinks the screen is the old size. (This is in CVS HEAD -- this code was
definitely different in 8.3 and before so the behaviour may be different).

Perhaps we need to tell readline whenever we run a subprocess and it may have
missed screen resize signals.

Hm, this Bash FAQ seems to indicate this shouldn't be a problem -- the whole
process group is supposed to get the window size. Psql isn't doing the job
control stuff the FAQ entry talks about so the pager ought to be in the same
process group. So I'm puzzled.

http://tiswww.case.edu/php/chet/bash/FAQ

-> E11) If I resize my xterm while another program is running, why doesn't bash
-> notice the change?
->
-> This is another issue that deals with job control.
->
-> The kernel maintains a notion of a current terminal process group. Members
-> of this process group (processes whose process group ID is equal to the
-> current terminal process group ID) receive terminal-generated signals like
-> SIGWINCH. (For more details, see the JOB CONTROL section of the bash
-> man page.)
->
-> If a terminal is resized, the kernel sends SIGWINCH to each member of
-> the terminal's current process group (the `foreground' process group).
->
-> When bash is running with job control enabled, each pipeline (which may be
-> a single command) is run in its own process group, different from bash's
-> process group. This foreground process group receives the SIGWINCH; bash
-> does not. Bash has no way of knowing that the terminal has been resized.
->
-> There is a `checkwinsize' option, settable with the `shopt' builtin, that
-> will cause bash to check the window size and adjust its idea of the
-> terminal's dimensions each time a process stops or exits and returns control
-> of the terminal to bash. Enable it with `shopt -s checkwinsize'.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

On Mon, Oct 27, 2008 at 3:59 AM, wstrzalka <wstrzalka@gmail.com> wrote:

I'm using psql mainly in putty window.

I have a problem while resizing the window.
When changing the window size (and those chars per row) psql output
becomes mess, the only rescue is to exit and run the psql again. It
looks like it's initializing the output params at startup and don't
refresh it in runtime.
Is there any way to deal with it? Or maybe some patch to psql could be
applied? If shell console or vi can work this way why not psql?

I see this once in a while with ssh sessions from linux to linux. But
usually everything is worse on windows :-).

merlin

Gregory Stark escribi�:

Hm, this Bash FAQ seems to indicate this shouldn't be a problem -- the whole
process group is supposed to get the window size. Psql isn't doing the job
control stuff the FAQ entry talks about so the pager ought to be in the same
process group. So I'm puzzled.

How do you know that the pager is in the same process group? Is the
process group something that's inherited automatically on fork()? The
setsid() manpage says so, but maybe we're missing something else.

I can confirm that when the pager is open, psql does not resize
properly. Maybe psql is ignoring signals while the pager is open, or
something.

Hmm, a quick experiment (8.3) reveals that psql doesn't seem to do
anything if I SIGWINCH it manually while the pager is open ...

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

How do you know that the pager is in the same process group? Is the
process group something that's inherited automatically on fork()?

It certainly should be.

I can confirm that when the pager is open, psql does not resize
properly. Maybe psql is ignoring signals while the pager is open, or
something.

If the pager is running, psql's not going to do anything anyway, no?
What behavior are you expecting?

regards, tom lane

Tom Lane escribi�:

Alvaro Herrera <alvherre@commandprompt.com> writes:

I can confirm that when the pager is open, psql does not resize
properly. Maybe psql is ignoring signals while the pager is open, or
something.

If the pager is running, psql's not going to do anything anyway, no?
What behavior are you expecting?

I am expecting that when control gets back to it, it has updated its
notion of terminal size. Obviously I don't want anything _visible_ to
happen at that point to psql.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

I can confirm that when the pager is open, psql does not resize
properly. Maybe psql is ignoring signals while the pager is open, or
something.

Hm, system() is documented to ignore SIGINT and SIGQUIT I wonder if it's
(erroneously?) ignoring SIGWINCH as well.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

Gregory Stark <stark@enterprisedb.com> writes:

Alvaro Herrera <alvherre@commandprompt.com> writes:

I can confirm that when the pager is open, psql does not resize
properly. Maybe psql is ignoring signals while the pager is open, or
something.

Hm, system() is documented to ignore SIGINT and SIGQUIT I wonder if it's
(erroneously?) ignoring SIGWINCH as well.

So far as I can see, psql itself doesn't cache screen dimension info
anyplace --- it does an ioctl(TIOCGWINSZ) every time it wants the
numbers. So if there is a problem here, it's not our bug; must be
readline's fault.

regards, tom lane

Messed up - I mean when going "up" and scrolling command history it
shows long queries (eg 2 line long) in single line and the exceeding
part overwrites the beginning of the query), or when writing long SQL
at some point I'm starting to overwriting it from the beginning of the
line.
Sometimes when editing query from the history and appending some
conditions at the end I'm starting to write in upper lines and some
query parts are duplicated there. Each key press moves me up and
shorter part of query is duplicated there.