MIME-Version: 1.0
References: 
 <CAFj8pRD2MOak45s8=bex3BcncJf2jt9ukx=i9pKmWB1SepZu6g@mail.gmail.com>
 <CAFj8pRDarWO-OsR+u0dWs=Y6aVOc+ebb_PJH8CdUuwmdOmR4tA@mail.gmail.com>
 <c978cb1a-c0e6-42f4-9a65-5f19dbf67682@uni-muenster.de>
In-Reply-To: <c978cb1a-c0e6-42f4-9a65-5f19dbf67682@uni-muenster.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Fri, 24 Apr 2026 08:56:36 +0200
Message-ID: 
 <CAFj8pRBnpqCUWtDZvpBJ+jExVWYPxDuJdfw8HLGt9bmeEBr=eQ@mail.gmail.com>
Subject: Re: PoC - psql - emphases line with table name in verbose output
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000005cd68006502f4602"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRBnpqCUWtDZvpBJ%2BjExVWYPxDuJdfw8HLGt9bmeEBr%3DeQ%40mail.gmail.com>
Precedence: bulk

--0000000000005cd68006502f4602
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

=C4=8Dt 23. 4. 2026 v 17:17 odes=C3=ADlatel Jim Jones <jim.jones@uni-muenst=
er.de>
napsal:

> Hi Pavel
>
> On 14/04/2026 05:42, Pavel Stehule wrote:
> > rebase, new commit message and minor cleaning
> Thanks for the patch!
>
> I tested the patch and setting PG_COLOR highlights the INFO messages.
>
> A few observations:
>
> =3D=3D string matching is locale-fragile =3D=3D
>
> Since the code relies on these fixed strings ...
>
> if (level =3D=3D PG_LOG_INFO && sgr_info_command &&
>   (strncmp(buf, "INFO:  vacuuming", strlen("INFO:  vacuuming")) =3D=3D 0 =
||
>    strncmp(buf, "INFO:  repacking", strlen("INFO:  repacking")) =3D=3D 0 =
||
>    strncmp(buf, "INFO:  analyzing", strlen("INFO:  analyzing")) =3D=3D 0)=
)
>
> .. the conditions only work if lc_messages is set to English. For
> instance, in German you get a different string, which means that
> highlighting won't work:
>
> $ psql postgres -c "VACUUM VERBOSE pg_class;" 2>&1 | grep INFO
> INFO:  Vacuum von =C2=BBpostgres.pg_catalog.pg_class=C2=AB
> INFO:  beende Vacuum der Tabelle =C2=BBpostgres.pg_catalog.pg_class=C2=AB=
:
> Index-Scans: 0
>
> $ psql postgres -c "ANALYSE VERBOSE pg_class;" 2>&1 | grep INFO
> INFO:  analysiere =C2=BBpg_catalog.pg_class=C2=AB
> INFO:  =C2=BBpg_class=C2=AB: 15 von 15 Seiten gelesen, enthalten 452 lebe=
nde
> Zeilen und 0 tote Zeilen; 452 Zeilen in Stichprobe, sch=C3=A4tzungsweise =
452
> Zeilen insgesamt
> INFO:  finished analyzing table "postgres.pg_catalog.pg_class"
>
> =3D=3D fixed command list =3D=3D
>
> Future verbose operations, if not added to this list, would silently get
> no highlighting.
>
> I'm wondering if it is possible to achieve it (locale-agnostic) only for
> certain commands without touching the code on the server side. Only by
> checking strings it'll be difficult to identify which INFO messages to
> highlight.
>

I am afraid this is the end of this direction. :-/

Please, can you check the functionality (only in english). I am interested
if this is just helpful and if it makes sense to continue in this feature.
Unfortunately, there are not too many possibilities about possible formats,
colors in terminals (that can work mostly everywhere).

I don't think it is possible to implement this without  communication
protocol enhancement. And if we will do this, the next question is if we
cannot use this for some more complex information about the executed
command.

For example - I thought about the possibility of teaching psql to read
progress stat tables - so can be nice, if the server can send some
information to client - maybe pgstat_progres_update can send INFO

like - "emphasize: nextinfo, pid: xxxx, progress table: pg_stat_vacuum,
commandtype: vacuum, ....

Maybe a different approach - instead of a plain text message, we can send
messages of this type in client side parsable format - if I am not wrong,
we are able to parse json on client side. json is still readable for humans
for old clients. On the client side we decide what and how we will display.
This can be more generic than just for VERBOSE mode of ANALYZE, VACUUM or
REINDEX.

some like

elog(INFO_CLIENT, '{ "cmdtag": "VACUUM", "state":"started", "progress_tab":
"pg_stat_progress_vacuum", "table_name": "yyy", "schema_name":"xxx", ...)

elog(INFO_CLIENT, '{"cmdatag": "VACUUM", "state":"finished",
"pages_removed": 0, "pages_ ...

I don't see some simple and nice solution at this moment. Maybe just using
new line after INFO with details

so results can looks like

INFO:  vacuuming "postgres.pg_catalog.pg_class"
INFO:  finished vacuuming "postgres.pg_catalog.pg_class": index scans: 0
pages: 0 removed, 15 remain, 15 scanned (100.00% of total), 0 eagerly
scanned
tuples: 0 removed, 452 remain, 0 are dead but not yet removable
removable cutoff: 701, which was 0 XIDs old when operation ended
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
visibility map: 0 pages set all-visible, 0 pages set all-frozen (0 were
all-visible)
index scan not needed: 0 pages from table (0.00% of total) had 0 dead item
identifiers removed
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
buffer usage: 75 hits, 0 reads, 0 dirtied
WAL usage: 0 records, 0 full page images, 0 bytes, 0 full page image bytes,
0 buffers full
memory usage: dead item storage 0.02 MB accumulated across 0 resets (limit
64.00 MB each)
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

INFO:  vacuuming "postgres.pg_catalog.pg_proc"
INFO:  finished vacuuming "postgres.pg_catalog.pg_proc": index scans: 0
pages: 0 removed, 101 remain, 1 scanned (0.99% of total), 0 eagerly scanned
tuples: 0 removed, 3437 remain, 0 are dead but not yet removable
removable cutoff: 701, which was 0 XIDs old when operation ended
new relfrozenxid: 701, which is 17 XIDs ahead of previous value
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
visibility map: 0 pages set all-visible, 0 pages set all-frozen (0 were
all-visible)
index scan not needed: 0 pages from table (0.00% of total) had 0 dead item
identifiers removed
avg read rate: 4.534 MB/s, avg write rate: 1.133 MB/s
buffer usage: 15 hits, 4 reads, 1 dirtied
WAL usage: 1 records, 1 full page images, 5871 bytes, 5752 full page image
bytes, 0 buffers full
memory usage: dead item storage 0.02 MB accumulated across 0 resets (limit
64.00 MB each)
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

INFO:  vacuuming "postgres.pg_toast.pg_toast_1255"
INFO:  finished vacuuming "postgres.pg_toast.pg_toast_1255": index scans: 0
pages: 0 removed, 2 remain, 2 scanned (100.00% of total), 0 eagerly scanned
tuples: 0 removed, 7 remain, 0 are dead but not yet removable
removable cutoff: 701, which was 0 XIDs old when operation ended
new relfrozenxid: 701, which is 17 XIDs ahead of previous value
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
visibility map: 0 pages set all-visible, 0 pages set all-frozen (0 were
all-visible)
index scan not needed: 0 pages from table (0.00% of total) had 0 dead item
identifiers removed
avg read rate: 19.462 MB/s, avg write rate: 2.780 MB/s
buffer usage: 36 hits, 7 reads, 1 dirtied
WAL usage: 1 records, 1 full page images, 4255 bytes, 4136 full page image
bytes, 0 buffers full
memory usage: dead item storage 0.02 MB accumulated across 0 resets (limit
64.00 MB each)
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

This is small change and maybe it can be enough

Regards

Pavel


> Thanks!
>
> Best, Jim
>
>

--0000000000005cd68006502f4602
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi</div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=C4=8Dt 23. 4. 20=
26 v=C2=A017:17 odes=C3=ADlatel Jim Jones &lt;<a href=3D"mailto:jim.jones@u=
ni-muenster.de" target=3D"_blank">jim.jones@uni-muenster.de</a>&gt; napsal:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pavel<br>
<br>
On 14/04/2026 05:42, Pavel Stehule wrote:<br>
&gt; rebase, new commit message and minor cleaning<br>
Thanks for the patch!<br>
<br>
I tested the patch and setting PG_COLOR highlights the INFO messages.<br>
<br>
A few observations:<br>
<br>
=3D=3D string matching is locale-fragile =3D=3D<br>
<br>
Since the code relies on these fixed strings ...<br>
<br>
if (level =3D=3D PG_LOG_INFO &amp;&amp; sgr_info_command &amp;&amp;<br>
=C2=A0 (strncmp(buf, &quot;INFO:=C2=A0 vacuuming&quot;, strlen(&quot;INFO:=
=C2=A0 vacuuming&quot;)) =3D=3D 0 ||<br>
=C2=A0 =C2=A0strncmp(buf, &quot;INFO:=C2=A0 repacking&quot;, strlen(&quot;I=
NFO:=C2=A0 repacking&quot;)) =3D=3D 0 ||<br>
=C2=A0 =C2=A0strncmp(buf, &quot;INFO:=C2=A0 analyzing&quot;, strlen(&quot;I=
NFO:=C2=A0 analyzing&quot;)) =3D=3D 0))<br>
<br>
.. the conditions only work if lc_messages is set to English. For<br>
instance, in German you get a different string, which means that<br>
highlighting won&#39;t work:<br>
<br>
$ psql postgres -c &quot;VACUUM VERBOSE pg_class;&quot; 2&gt;&amp;1 | grep =
INFO<br>
INFO:=C2=A0 Vacuum von =C2=BBpostgres.pg_catalog.pg_class=C2=AB<br>
INFO:=C2=A0 beende Vacuum der Tabelle =C2=BBpostgres.pg_catalog.pg_class=C2=
=AB:<br>
Index-Scans: 0<br>
<br>
$ psql postgres -c &quot;ANALYSE VERBOSE pg_class;&quot; 2&gt;&amp;1 | grep=
 INFO<br>
INFO:=C2=A0 analysiere =C2=BBpg_catalog.pg_class=C2=AB<br>
INFO:=C2=A0 =C2=BBpg_class=C2=AB: 15 von 15 Seiten gelesen, enthalten 452 l=
ebende<br>
Zeilen und 0 tote Zeilen; 452 Zeilen in Stichprobe, sch=C3=A4tzungsweise 45=
2<br>
Zeilen insgesamt<br>
INFO:=C2=A0 finished analyzing table &quot;postgres.pg_catalog.pg_class&quo=
t;<br>
<br>
=3D=3D fixed command list =3D=3D<br>
<br>
Future verbose operations, if not added to this list, would silently get<br=
>
no highlighting.<br>
<br>
I&#39;m wondering if it is possible to achieve it (locale-agnostic) only fo=
r<br>
certain commands without touching the code on the server side. Only by<br>
checking strings it&#39;ll be difficult to identify which INFO messages to<=
br>
highlight.<br></blockquote><div><br></div><div>I am afraid this is the end =
of this direction. :-/=C2=A0</div><div><br></div><div>Please, can you check=
 the functionality (only in english). I am interested if this is just helpf=
ul and if it makes sense to continue in this feature. Unfortunately, there =
are not too many possibilities about possible formats, colors in terminals =
(that can work mostly everywhere).=C2=A0</div><br></div><div class=3D"gmail=
_quote">I don&#39;t think it is possible to implement this without=C2=A0 co=
mmunication protocol enhancement. And if we will do this, the next question=
 is if we cannot use this for some more complex information about the execu=
ted command.</div><div class=3D"gmail_quote"><div><br></div><div>For exampl=
e - I thought about the possibility of teaching psql to read progress stat =
tables - so can be nice, if the server can send some information to client =
- maybe pgstat_progres_update can send INFO=C2=A0</div><div><br></div><div>=
like - &quot;emphasize: nextinfo, pid: xxxx, progress table: pg_stat_vacuum=
, commandtype: vacuum, ....</div><div><br></div><div>Maybe a different appr=
oach=C2=A0- instead of a plain text message, we can send messages of this t=
ype in client side parsable format - if I am not wrong, we are able to pars=
e json on client side. json is still readable for humans for old clients. O=
n the client side we decide what and how we will display. This can be more =
generic than just for VERBOSE mode of ANALYZE, VACUUM or REINDEX.</div><div=
><br></div><div>some like</div><div><br></div><div>elog(INFO_CLIENT, &#39;{=
 &quot;cmdtag&quot;: &quot;VACUUM&quot;, &quot;state&quot;:&quot;started&qu=
ot;, &quot;progress_tab&quot;: &quot;pg_stat_progress_vacuum&quot;, &quot;t=
able_name&quot;: &quot;yyy&quot;, &quot;schema_name&quot;:&quot;xxx&quot;, =
...)</div><div><br></div><div>elog(INFO_CLIENT, &#39;{&quot;cmdatag&quot;: =
&quot;VACUUM&quot;, &quot;state&quot;:&quot;finished&quot;, &quot;pages_rem=
oved&quot;: 0, &quot;pages_ ...</div><div><br></div><div>I don&#39;t see so=
me simple and nice solution at this moment. Maybe just using new line after=
 INFO with details</div><div><br></div><div>so results can looks like</div>=
<div><br></div><div>INFO: =C2=A0vacuuming &quot;postgres.pg_catalog.pg_clas=
s&quot;<br>INFO: =C2=A0finished vacuuming &quot;postgres.pg_catalog.pg_clas=
s&quot;: index scans: 0<br>pages: 0 removed, 15 remain, 15 scanned (100.00%=
 of total), 0 eagerly scanned<br>tuples: 0 removed, 452 remain, 0 are dead =
but not yet removable<br>removable cutoff: 701, which was 0 XIDs old when o=
peration ended<br>frozen: 0 pages from table (0.00% of total) had 0 tuples =
frozen<br>visibility map: 0 pages set all-visible, 0 pages set all-frozen (=
0 were all-visible)<br>index scan not needed: 0 pages from table (0.00% of =
total) had 0 dead item identifiers removed<br>avg read rate: 0.000 MB/s, av=
g write rate: 0.000 MB/s<br>buffer usage: 75 hits, 0 reads, 0 dirtied<br>WA=
L usage: 0 records, 0 full page images, 0 bytes, 0 full page image bytes, 0=
 buffers full<br>memory usage: dead item storage 0.02 MB accumulated across=
 0 resets (limit 64.00 MB each)<br>system usage: CPU: user: 0.00 s, system:=
 0.00 s, elapsed: 0.00 s<br><br>INFO: =C2=A0vacuuming &quot;postgres.pg_cat=
alog.pg_proc&quot;<br>INFO: =C2=A0finished vacuuming &quot;postgres.pg_cata=
log.pg_proc&quot;: index scans: 0<br>pages: 0 removed, 101 remain, 1 scanne=
d (0.99% of total), 0 eagerly scanned<br>tuples: 0 removed, 3437 remain, 0 =
are dead but not yet removable<br>removable cutoff: 701, which was 0 XIDs o=
ld when operation ended<br>new relfrozenxid: 701, which is 17 XIDs ahead of=
 previous value<br>frozen: 0 pages from table (0.00% of total) had 0 tuples=
 frozen<br>visibility map: 0 pages set all-visible, 0 pages set all-frozen =
(0 were all-visible)<br>index scan not needed: 0 pages from table (0.00% of=
 total) had 0 dead item identifiers removed<br>avg read rate: 4.534 MB/s, a=
vg write rate: 1.133 MB/s<br>buffer usage: 15 hits, 4 reads, 1 dirtied<br>W=
AL usage: 1 records, 1 full page images, 5871 bytes, 5752 full page image b=
ytes, 0 buffers full<br>memory usage: dead item storage 0.02 MB accumulated=
 across 0 resets (limit 64.00 MB each)<br>system usage: CPU: user: 0.00 s, =
system: 0.00 s, elapsed: 0.00 s<br><br>INFO: =C2=A0vacuuming &quot;postgres=
.pg_toast.pg_toast_1255&quot;<br>INFO: =C2=A0finished vacuuming &quot;postg=
res.pg_toast.pg_toast_1255&quot;: index scans: 0<br>pages: 0 removed, 2 rem=
ain, 2 scanned (100.00% of total), 0 eagerly scanned<br>tuples: 0 removed, =
7 remain, 0 are dead but not yet removable<br>removable cutoff: 701, which =
was 0 XIDs old when operation ended<br>new relfrozenxid: 701, which is 17 X=
IDs ahead of previous value<br>frozen: 0 pages from table (0.00% of total) =
had 0 tuples frozen<br>visibility map: 0 pages set all-visible, 0 pages set=
 all-frozen (0 were all-visible)<br>index scan not needed: 0 pages from tab=
le (0.00% of total) had 0 dead item identifiers removed<br>avg read rate: 1=
9.462 MB/s, avg write rate: 2.780 MB/s<br>buffer usage: 36 hits, 7 reads, 1=
 dirtied<br>WAL usage: 1 records, 1 full page images, 4255 bytes, 4136 full=
 page image bytes, 0 buffers full<br>memory usage: dead item storage 0.02 M=
B accumulated across 0 resets (limit 64.00 MB each)<br>system usage: CPU: u=
ser: 0.00 s, system: 0.00 s, elapsed: 0.00 s</div><div><br></div><div>This =
is small change and maybe it can be enough=C2=A0</div><div><br></div><div>R=
egards</div><div><br></div><div>Pavel</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
Thanks!<br>
<br>
Best, Jim<br>
<br>
</blockquote></div></div>
</div>
</div>

--0000000000005cd68006502f4602--