Re: proposal - psql - use pager for \watch command

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - psql - use pager for \watch command
Date: 2021-02-18 08:16:35
Message-ID: CAFj8pRB1K1RG=MeJzLhad2hVoeQgug-MPcRmb0o5d_MHzqd2AQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

út 16. 2. 2021 v 2:49 odesílatel Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
napsal:

> On Fri, Jan 8, 2021 at 10:36 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > ne 19. 4. 2020 v 19:27 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
> >> last week I finished pspg 3.0 https://github.com/okbob/pspg . pspg now
> supports pipes, named pipes very well. Today the pspg can be used as pager
> for output of \watch command. Sure, psql needs attached patch.
> >>
> >> I propose new psql environment variable PSQL_WATCH_PAGER. When this
> variable is not empty, then \watch command starts specified pager, and
> redirect output to related pipe. When pipe is closed - by pager, then
> \watch cycle is leaved.
> >>
> >> If you want to test proposed feature, you need a pspg with
> cb4114f98318344d162a84b895a3b7f8badec241 commit.
> >>
> >> Then you can set your env
> >>
> >> export PSQL_WATCH_PAGER="pspg --stream"
> >> psql
> >>
> >> SELECT * FROM pg_stat_database;
> >> \watch 1
> >>
> >> Comments, notes?
>
> I tried this out with pspg 4.1 from my package manager. It seems
> really useful, especially for demos. I like it!
>

Thank you :)

> * Set up rendering options, in particular, disable the pager,
> because
> * nobody wants to be prompted while watching the output of
> 'watch'.
> */
> - myopt.topt.pager = 0;
> + if (!pagerpipe)
> + myopt.topt.pager = 0;
>
> Obsolete comment.
>
> +static bool sigpipe_received = false;
>
> This should be "static volatile sig_atomic_t", and I suppose our
> convention name for that variable would be got_SIGPIPE. Would it be
> possible to ignore SIGPIPE instead, and then rely on another way of
> knowing that the pager has quit? But... hmm:
>
> - long s = Min(i, 1000L);
> + long s = Min(i, pagerpipe ? 100L :
> 1000L);
>
> I haven't studied this (preexisting) polling loop, but I don't like
> it. I understand that it's there because on some systems, pg_usleep()
> won't wake up for SIGINT (^C), but now it's being used for a secondary
> purpose, that I haven't fully understood. After I quit pspg (by
> pressing q) while running \watch 10, I have to wait until the end of a
> 10 second cycle before it tries to write to the pipe again, unless I
> also press ^C. I feel like it has to be possible to achieve "precise"
> behaviour somehow when you quit; maybe something like waiting for
> readiness on the pager's stderr, or something like that -- I haven't
> thought hard about this and I admit that I have no idea how this works
> on Windows.
>

I'll look there.

> Sometimes I see a message like this after I quit pspg:
>
> postgres=# \watch 10
> input stream was closed
>

This is a pspg's message. It's a little bit strange, because this message
comes from event reading, and in the end, the pspg doesn't read events. So
it looks like the pspg issue, and I have to check it.

I have one question - now, the pspg has to do complex heuristics to detect
an start and an end of data in an stream. Can we, in this case (when
PSQL_WATCH_PAGER is active), use invisible chars STX and ETX or maybe ETB?
It can be a special \pset option. Surely, the detection of these chars
should be much more robust than current pspg's heuristics.

Regards

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-02-18 08:17:37 Re: ERROR: "ft1" is of the wrong type.
Previous Message Kyotaro Horiguchi 2021-02-18 08:06:25 Re: Is it worth accepting multiple CRLs?