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?

Search Discussions

  • Peter Eisentraut at Oct 27, 2008 at 10:50 am

    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.
  • Sam Mason at Oct 27, 2008 at 12:16 pm

    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
  • Wstrzalka at Oct 28, 2008 at 7:03 pm

    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.
  • Gregory Stark at Oct 29, 2008 at 10:58 am

    wstrzalka 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 at Oct 29, 2008 at 11:23 am

    Gregory Stark 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!
  • Alvaro Herrera at Oct 29, 2008 at 3:50 pm

    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
  • Tom Lane at Oct 29, 2008 at 4:06 pm

    Alvaro Herrera 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
  • Alvaro Herrera at Oct 29, 2008 at 4:11 pm

    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
  • Gregory Stark at Oct 30, 2008 at 10:52 pm

    Alvaro Herrera 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!
  • Tom Lane at Oct 30, 2008 at 11:01 pm

    Gregory Stark 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
  • Wstrzalka at Nov 3, 2008 at 8:04 am
    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.
  • Merlin Moncure at Oct 29, 2008 at 12:19 pm

    On Mon, Oct 27, 2008 at 3:59 AM, 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?
    I see this once in a while with ssh sessions from linux to linux. But
    usually everything is worse on windows :-).

    merlin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedOct 27, '08 at 9:03a
activeNov 3, '08 at 8:04a
posts13
users7
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase