Horton

Thread

Commits

  1. Tighten usage of PSQL_WATCH_PAGER.

  2. Add tab-completion for newly added SUBSCRIPTION options.

  3. psql: add an optional execution-count limit to \watch.

  4. Handle empty or all-blank PAGER setting more sanely in psql.

  1. psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-09T06:52:18Z

    Hi

I try run make check-world. Now I have problems with tests of psql

I had to cancel tests

log:

[08:46:49.828](0.038s) ok 63 - no ON_ERROR_STOP, --single-transaction and
multiple -c switches
[08:46:49.860](0.033s) ok 64 - client-side error commits transaction, no
ON_ERROR_STOP and multiple -c switches
[08:46:49.928](0.067s) ok 65 - \copy from with DEFAULT: exit code 0
[08:46:49.929](0.001s) ok 66 - \copy from with DEFAULT: no stderr
[08:46:49.930](0.001s) ok 67 - \copy from with DEFAULT: matches
death by signal at
/home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/perl/PostgreSQL/Test/Cluster.pm
line 3042.
# Postmaster PID for node "main" is 157863
### Stopping node "main" using mode immediate
# Running: pg_ctl -D
/home/pavel/src/postgresql.master/src/bin/psql/tmp_check/t_001_basic_main_data/pgdata
-m immediate stop
waiting for server to shut down.... done
server stopped
# No postmaster PID for node "main"
[08:47:30.361](40.431s) # Tests were run but no plan was declared and
done_testing() was not seen.
[08:47:30.362](0.001s) # Looks like your test exited with 4 just after 67.
Warning: unable to close filehandle $orig_stderr properly: Broken pipe
during global destruction.

I use Fedora 38

Regards

Pavel

  2. Re: psql tests hangs

    Daniel Gustafsson <daniel@yesql.se> — 2023-05-09T08:48:08Z

    > On 9 May 2023, at 08:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 
> Hi
> 
> I try run make check-world. Now I have problems with tests of psql
> 
> I had to cancel tests
> 
> log:
> 
> [08:46:49.828](0.038s) ok 63 - no ON_ERROR_STOP, --single-transaction and multiple -c switches
> [08:46:49.860](0.033s) ok 64 - client-side error commits transaction, no ON_ERROR_STOP and multiple -c switches
> [08:46:49.928](0.067s) ok 65 - \copy from with DEFAULT: exit code 0
> [08:46:49.929](0.001s) ok 66 - \copy from with DEFAULT: no stderr
> [08:46:49.930](0.001s) ok 67 - \copy from with DEFAULT: matches
> death by signal at /home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/perl/PostgreSQL/Test/Cluster.pm line 3042.
> # Postmaster PID for node "main" is 157863
> ### Stopping node "main" using mode immediate
> # Running: pg_ctl -D /home/pavel/src/postgresql.master/src/bin/psql/tmp_check/t_001_basic_main_data/pgdata -m immediate stop
> waiting for server to shut down.... done
> server stopped
> # No postmaster PID for node "main"
> [08:47:30.361](40.431s) # Tests were run but no plan was declared and done_testing() was not seen.
> [08:47:30.362](0.001s) # Looks like your test exited with 4 just after 67.
> Warning: unable to close filehandle $orig_stderr properly: Broken pipe during global destruction.

I'm unable to reproduce, and this clearly works in the buildfarm and CI.  Did
you run out of disk on the volume during the test or something similar?
Anything interesting in the serverlogs from the tmp_check install?

--
Daniel Gustafsson

  3. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-09T09:07:02Z

    út 9. 5. 2023 v 10:48 odesílatel Daniel Gustafsson <daniel@yesql.se> napsal:

> > On 9 May 2023, at 08:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> > Hi
> >
> > I try run make check-world. Now I have problems with tests of psql
> >
> > I had to cancel tests
> >
> > log:
> >
> > [08:46:49.828](0.038s) ok 63 - no ON_ERROR_STOP, --single-transaction
> and multiple -c switches
> > [08:46:49.860](0.033s) ok 64 - client-side error commits transaction, no
> ON_ERROR_STOP and multiple -c switches
> > [08:46:49.928](0.067s) ok 65 - \copy from with DEFAULT: exit code 0
> > [08:46:49.929](0.001s) ok 66 - \copy from with DEFAULT: no stderr
> > [08:46:49.930](0.001s) ok 67 - \copy from with DEFAULT: matches
> > death by signal at
> /home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/perl/PostgreSQL/Test/Cluster.pm
> line 3042.
> > # Postmaster PID for node "main" is 157863
> > ### Stopping node "main" using mode immediate
> > # Running: pg_ctl -D
> /home/pavel/src/postgresql.master/src/bin/psql/tmp_check/t_001_basic_main_data/pgdata
> -m immediate stop
> > waiting for server to shut down.... done
> > server stopped
> > # No postmaster PID for node "main"
> > [08:47:30.361](40.431s) # Tests were run but no plan was declared and
> done_testing() was not seen.
> > [08:47:30.362](0.001s) # Looks like your test exited with 4 just after
> 67.
> > Warning: unable to close filehandle $orig_stderr properly: Broken pipe
> during global destruction.
>
> I'm unable to reproduce, and this clearly works in the buildfarm and CI.
> Did
> you run out of disk on the volume during the test or something similar?
> Anything interesting in the serverlogs from the tmp_check install?
>

I have enough free space on disc

I don't see nothing interesting in log (it is another run)

2023-05-09 08:50:04.839 CEST [158930] 001_basic.pl LOG:  statement: COPY
 copy_default FROM STDIN with (format 'csv', default 'placeholder');
2023-05-09 08:50:04.841 CEST [158930] 001_basic.pl LOG:  statement: SELECT
* FROM copy_default
2023-05-09 08:50:04.879 CEST [158932] 001_basic.pl LOG:  statement: SELECT
1.
2023-05-09 08:50:04.888 CEST [158932] 001_basic.pl LOG:  statement: SELECT
1.
2023-05-09 08:50:04.898 CEST [158932] 001_basic.pl LOG:  statement: SELECT
1.
2023-05-09 08:50:28.375 CEST [158862] LOG:  received immediate shutdown
request
2023-05-09 08:50:28.385 CEST [158862] LOG:  database system is shut down

backtrace from perl

Program received signal SIGINT, Interrupt.
0x00007f387ecc1ade in select () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f387ecc1ade in select () from /lib64/libc.so.6
#1  0x00007f387e97363b in Perl_pp_sselect () from /lib64/libperl.so.5.36
#2  0x00007f387e917958 in Perl_runops_standard () from
/lib64/libperl.so.5.36
#3  0x00007f387e88259d in perl_run () from /lib64/libperl.so.5.36
#4  0x00005588bceb234a in main ()

Regards

Pavel



   1.






>
> --
> Daniel Gustafsson
>
>

  4. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-09T11:53:07Z

    út 9. 5. 2023 v 11:07 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

>
>
> út 9. 5. 2023 v 10:48 odesílatel Daniel Gustafsson <daniel@yesql.se>
> napsal:
>
>> > On 9 May 2023, at 08:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> >
>> > Hi
>> >
>> > I try run make check-world. Now I have problems with tests of psql
>> >
>> > I had to cancel tests
>> >
>> > log:
>> >
>> > [08:46:49.828](0.038s) ok 63 - no ON_ERROR_STOP, --single-transaction
>> and multiple -c switches
>> > [08:46:49.860](0.033s) ok 64 - client-side error commits transaction,
>> no ON_ERROR_STOP and multiple -c switches
>> > [08:46:49.928](0.067s) ok 65 - \copy from with DEFAULT: exit code 0
>> > [08:46:49.929](0.001s) ok 66 - \copy from with DEFAULT: no stderr
>> > [08:46:49.930](0.001s) ok 67 - \copy from with DEFAULT: matches
>> > death by signal at
>> /home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/perl/PostgreSQL/Test/Cluster.pm
>> line 3042.
>> > # Postmaster PID for node "main" is 157863
>> > ### Stopping node "main" using mode immediate
>> > # Running: pg_ctl -D
>> /home/pavel/src/postgresql.master/src/bin/psql/tmp_check/t_001_basic_main_data/pgdata
>> -m immediate stop
>> > waiting for server to shut down.... done
>> > server stopped
>> > # No postmaster PID for node "main"
>> > [08:47:30.361](40.431s) # Tests were run but no plan was declared and
>> done_testing() was not seen.
>> > [08:47:30.362](0.001s) # Looks like your test exited with 4 just after
>> 67.
>> > Warning: unable to close filehandle $orig_stderr properly: Broken pipe
>> during global destruction.
>>
>> I'm unable to reproduce, and this clearly works in the buildfarm and CI.
>> Did
>> you run out of disk on the volume during the test or something similar?
>> Anything interesting in the serverlogs from the tmp_check install?
>>
>
> I have enough free space on disc
>
> I don't see nothing interesting in log (it is another run)
>
> 2023-05-09 08:50:04.839 CEST [158930] 001_basic.pl LOG:  statement: COPY
>  copy_default FROM STDIN with (format 'csv', default 'placeholder');
> 2023-05-09 08:50:04.841 CEST [158930] 001_basic.pl LOG:  statement:
> SELECT * FROM copy_default
> 2023-05-09 08:50:04.879 CEST [158932] 001_basic.pl LOG:  statement:
> SELECT 1.
> 2023-05-09 08:50:04.888 CEST [158932] 001_basic.pl LOG:  statement:
> SELECT 1.
> 2023-05-09 08:50:04.898 CEST [158932] 001_basic.pl LOG:  statement:
> SELECT 1.
> 2023-05-09 08:50:28.375 CEST [158862] LOG:  received immediate shutdown
> request
> 2023-05-09 08:50:28.385 CEST [158862] LOG:  database system is shut down
>
> backtrace from perl
>
> Program received signal SIGINT, Interrupt.
> 0x00007f387ecc1ade in select () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007f387ecc1ade in select () from /lib64/libc.so.6
> #1  0x00007f387e97363b in Perl_pp_sselect () from /lib64/libperl.so.5.36
> #2  0x00007f387e917958 in Perl_runops_standard () from
> /lib64/libperl.so.5.36
> #3  0x00007f387e88259d in perl_run () from /lib64/libperl.so.5.36
> #4  0x00005588bceb234a in main ()
>
> Regards
>

I repeated another build with the same result.

Tested REL_15_STABLE branch without any problems.

Regards

Pavel




>
> Pavel
>
>
>
>    1.
>
>
>
>
>
>
>>
>> --
>> Daniel Gustafsson
>>
>>

  5. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-09T18:31:23Z

    Hi


út 9. 5. 2023 v 13:53 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

>
>
> út 9. 5. 2023 v 11:07 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
> napsal:
>
>>
>>
>> út 9. 5. 2023 v 10:48 odesílatel Daniel Gustafsson <daniel@yesql.se>
>> napsal:
>>
>>> > On 9 May 2023, at 08:52, Pavel Stehule <pavel.stehule@gmail.com>
>>> wrote:
>>> >
>>> > Hi
>>> >
>>> > I try run make check-world. Now I have problems with tests of psql
>>> >
>>> > I had to cancel tests
>>> >
>>> > log:
>>> >
>>> > [08:46:49.828](0.038s) ok 63 - no ON_ERROR_STOP, --single-transaction
>>> and multiple -c switches
>>> > [08:46:49.860](0.033s) ok 64 - client-side error commits transaction,
>>> no ON_ERROR_STOP and multiple -c switches
>>> > [08:46:49.928](0.067s) ok 65 - \copy from with DEFAULT: exit code 0
>>> > [08:46:49.929](0.001s) ok 66 - \copy from with DEFAULT: no stderr
>>> > [08:46:49.930](0.001s) ok 67 - \copy from with DEFAULT: matches
>>> > death by signal at
>>> /home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/perl/PostgreSQL/Test/Cluster.pm
>>> line 3042.
>>> > # Postmaster PID for node "main" is 157863
>>> > ### Stopping node "main" using mode immediate
>>> > # Running: pg_ctl -D
>>> /home/pavel/src/postgresql.master/src/bin/psql/tmp_check/t_001_basic_main_data/pgdata
>>> -m immediate stop
>>> > waiting for server to shut down.... done
>>> > server stopped
>>> > # No postmaster PID for node "main"
>>> > [08:47:30.361](40.431s) # Tests were run but no plan was declared and
>>> done_testing() was not seen.
>>> > [08:47:30.362](0.001s) # Looks like your test exited with 4 just after
>>> 67.
>>> > Warning: unable to close filehandle $orig_stderr properly: Broken pipe
>>> during global destruction.
>>>
>>> I'm unable to reproduce, and this clearly works in the buildfarm and
>>> CI.  Did
>>> you run out of disk on the volume during the test or something similar?
>>> Anything interesting in the serverlogs from the tmp_check install?
>>>
>>
>> I have enough free space on disc
>>
>> I don't see nothing interesting in log (it is another run)
>>
>> 2023-05-09 08:50:04.839 CEST [158930] 001_basic.pl LOG:  statement: COPY
>>  copy_default FROM STDIN with (format 'csv', default 'placeholder');
>> 2023-05-09 08:50:04.841 CEST [158930] 001_basic.pl LOG:  statement:
>> SELECT * FROM copy_default
>> 2023-05-09 08:50:04.879 CEST [158932] 001_basic.pl LOG:  statement:
>> SELECT 1.
>> 2023-05-09 08:50:04.888 CEST [158932] 001_basic.pl LOG:  statement:
>> SELECT 1.
>> 2023-05-09 08:50:04.898 CEST [158932] 001_basic.pl LOG:  statement:
>> SELECT 1.
>> 2023-05-09 08:50:28.375 CEST [158862] LOG:  received immediate shutdown
>> request
>> 2023-05-09 08:50:28.385 CEST [158862] LOG:  database system is shut down
>>
>> backtrace from perl
>>
>> Program received signal SIGINT, Interrupt.
>> 0x00007f387ecc1ade in select () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x00007f387ecc1ade in select () from /lib64/libc.so.6
>> #1  0x00007f387e97363b in Perl_pp_sselect () from /lib64/libperl.so.5.36
>> #2  0x00007f387e917958 in Perl_runops_standard () from
>> /lib64/libperl.so.5.36
>> #3  0x00007f387e88259d in perl_run () from /lib64/libperl.so.5.36
>> #4  0x00005588bceb234a in main ()
>>
>> Regards
>>
>
> I repeated another build with the same result.
>
> Tested REL_15_STABLE branch without any problems.
>

There is some dependence on locales

for commit  96c498d2f8ce5f0082c64793f94e2d0cfa7d7605

with my cs_CZ.utf8 locale

echo "# +++ tap check in src/bin/psql +++" && rm -rf
'/home/pavel/src/postgresql.master/src/bin/psql'/tmp_check &&
/usr/bin/mkdir -p
'/home/pavel/src/postgresql.master/src/bin/psql'/tmp_check && cd . &&
TESTLOGDIR='/home/pavel/src/postgresql.master/src/bin/psql/tmp_check/log'
TESTDATADIR='/home/pavel/src/postgresql.master/src/bin/psql/tmp_check'
PATH="/home/pavel/src/postgresql.master/tmp_install/usr/local/pgsql/bin:/home/pavel/src/postgresql.master/src/bin/psql:$PATH"
LD_LIBRARY_PATH="/home/pavel/src/postgresql.master/tmp_install/usr/local/pgsql/lib"
 PGPORT='65432'
top_builddir='/home/pavel/src/postgresql.master/src/bin/psql/../../..'
PG_REGRESS='/home/pavel/src/postgresql.master/src/bin/psql/../../../src/test/regress/pg_regress'
/usr/bin/prove -I ../../../src/test/perl/ -I .  t/*.pl
# +++ tap check in src/bin/psql +++
t/001_basic.pl ........... 15/?
#   Failed test '\watch with 3 iterations: exit code 0'
#   at t/001_basic.pl line 354.
#          got: '3'
#     expected: '0'

#   Failed test '\watch with 3 iterations: no stderr'
#   at t/001_basic.pl line 354.
#          got: 'psql:<stdin>:1: error: \watch: incorrect interval value
"0.01"'
#     expected: ''

#   Failed test '\watch with 3 iterations: matches'
#   at t/001_basic.pl line 354.
#                   ''
#     doesn't match '(?^:1\n1\n1)'
# Looks like you failed 3 tests of 80.
t/001_basic.pl ........... Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/80 subtests
t/010_tab_completion.pl .. ok
t/020_cancel.pl .......... ok

Test Summary Report
-------------------
t/001_basic.pl         (Wstat: 768 (exited 3) Tests: 80 Failed: 3)
  Failed tests:  68-70
  Non-zero exit status: 3
Files=3, Tests=170,  4 wallclock secs ( 0.09 usr  0.01 sys +  2.43 cusr
 1.24 csys =  3.77 CPU)
Result: FAIL
make: *** [Makefile:87: check] Chyba 1

with C lokale it hangs

It is broken from

commit 00beecfe839c878abb366b68272426ed5296bc2b (HEAD)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Apr 6 13:18:14 2023 -0400

    psql: add an optional execution-count limit to \watch.

    \watch can now be told to stop after N executions of the query.

    With the idea that we might want to add more options to \watch
    in future, this patch generalizes the command's syntax to a list
    of name=value options, with the interval allowed to omit the name
    for backwards compatibility.

    Andrey Borodin, reviewed by Kyotaro Horiguchi, Nathan Bossart,
    Michael Paquier, Yugo Nagata, and myself

    Discussion:
https://postgr.es/m/CAAhFRxiZ2-n_L1ErMm9AZjgmUK=qS6VHb+0SaMn8sqqbhF7How@mail.gmail.com

    Discussion:
http://postgr.es/m/CAPmGK15FuPVGx3TGHKShsbPKKtF1y58-ZLcKoxfN-nqLj1dZ%3Dg%40mail.gmail.com
[pavel@localhost postgresql.master]$ uname -a
Linux localhost.localdomain 6.2.14-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC
Mon May  1 00:55:28 UTC 2023 x86_64 GNU/Linux
[pavel@localhost postgresql.master]$ gcc --version
gcc (GCC) 13.1.1 20230426 (Red Hat 13.1.1-1)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Probably the locale problem was fixed - because test on master hangs always
without dependency on locale

Regards

Pavel



> Regards
>
> Pavel
>
>
>
>
>>
>> Pavel
>>
>>
>>
>>    1.
>>
>>
>>
>>
>>
>>
>>>
>>> --
>>> Daniel Gustafsson
>>>
>>>

  6. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-10T04:58:22Z

    Hi

When I remove this test, then all tests passed

diff --git a/src/bin/psql/t/001_basic.pl b/src/bin/psql/t/001_basic.pl
index 596746de17..631a1a7335 100644
--- a/src/bin/psql/t/001_basic.pl
+++ b/src/bin/psql/t/001_basic.pl
@@ -353,11 +353,6 @@ psql_like(

 # Check \watch
 # Note: the interval value is parsed with locale-aware strtod()
-psql_like(
-   $node,
-   sprintf('SELECT 1 \watch c=3 i=%g', 0.01),
-   qr/1\n1\n1/,
-   '\watch with 3 iterations');

 # Check \watch errors
 psql_fails_like(

Can somebody repeat this testing of FC38?

Regards

Pavel

  7. Re: psql tests hangs

    x4mmm@yandex-team.ru — 2023-05-11T09:36:37Z

    
> On 10 May 2023, at 09:58, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 
> When I remove this test, then all tests passed

Hi Pavel!

Can you plz share how sprintf('SELECT 1 \watch c=3 i=%g', 0.01) is formatting 0.01 on your system?
And try to run that string against psql.

As an alternative I propose to use "i=0”. I hope 0 is more locale-independent (but I’m not sure)… But the test's coverage will decrease.

Best regards, Andrey Borodin.

  8. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-11T12:59:43Z

    Hi


čt 11. 5. 2023 v 11:36 odesílatel Andrey M. Borodin <x4mmm@yandex-team.ru>
napsal:

>
>
> > On 10 May 2023, at 09:58, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> > When I remove this test, then all tests passed
>
> Hi Pavel!
>
> Can you plz share how sprintf('SELECT 1 \watch c=3 i=%g', 0.01) is
> formatting 0.01 on your system?
> And try to run that string against psql.
>
> As an alternative I propose to use "i=0”. I hope 0 is more
> locale-independent (but I’m not sure)… But the test's coverage will
> decrease.
>
> Best regards, Andrey Borodin.
>
>
[pavel@localhost psql]$ cat test.pl
use locale;
my $result = sprintf('SELECT 1 \watch c=3 i=%g', 0.01);
print ">>$result<<\n";

[pavel@localhost psql]$ perl test.pl
>>SELECT 1 \watch c=3 i=0,01<<
[pavel@localhost psql]$ LANG=C perl test.pl
>>SELECT 1 \watch c=3 i=0.01<<

Regards

Pavel

  9. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-11T18:44:39Z

    Pavel Stehule <pavel.stehule@gmail.com> writes:
> When I remove this test, then all tests passed

This works fine for me on Fedora 37:

$ cd src/bin/psql
$ LANG=cs_CZ.utf8 make installcheck
make -C ../../../src/backend generated-headers
make[1]: Vstupuje se do adresáře „/home/tgl/pgsql/src/backend“
...
# +++ tap install-check in src/bin/psql +++
t/001_basic.pl ........... ok    
t/010_tab_completion.pl .. ok    
t/020_cancel.pl .......... ok   
All tests successful.
Files=3, Tests=169,  6 wallclock secs ( 0.06 usr  0.02 sys +  2.64 cusr  0.99 csys =  3.71 CPU)
Result: PASS

I wonder if you have something inconsistent in your locale
configuration.  What do you see from

$ env | grep '^L[CA]'

			regards, tom lane

  10. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-11T19:06:01Z

    čt 11. 5. 2023 v 20:44 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > When I remove this test, then all tests passed
>
> This works fine for me on Fedora 37:
>

I have Fedora 38

>
> $ cd src/bin/psql
> $ LANG=cs_CZ.utf8 make installcheck
> make -C ../../../src/backend generated-headers
> make[1]: Vstupuje se do adresáře „/home/tgl/pgsql/src/backend“
> ...
> # +++ tap install-check in src/bin/psql +++
> t/001_basic.pl ........... ok
> t/010_tab_completion.pl .. ok
> t/020_cancel.pl .......... ok
> All tests successful.
> Files=3, Tests=169,  6 wallclock secs ( 0.06 usr  0.02 sys +  2.64 cusr
> 0.99 csys =  3.71 CPU)
> Result: PASS
>
> I wonder if you have something inconsistent in your locale
> configuration.  What do you see from
>
> $ env | grep '^L[CA]'
>

 [pavel@localhost psql]$ env | grep '^L[CA]'
LANG=cs_CZ.UTF-8

Regards

Pavel



>                         regards, tom lane
>

  11. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-11T19:15:12Z

    On Thu, May 11, 2023 at 3:06 PM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

>
>
> čt 11. 5. 2023 v 20:44 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> > When I remove this test, then all tests passed
>>
>> This works fine for me on Fedora 37:
>>
>
> I have Fedora 38
>
>>
>> $ cd src/bin/psql
>> $ LANG=cs_CZ.utf8 make installcheck
>> make -C ../../../src/backend generated-headers
>> make[1]: Vstupuje se do adresáře „/home/tgl/pgsql/src/backend“
>> ...
>> # +++ tap install-check in src/bin/psql +++
>> t/001_basic.pl ........... ok
>> t/010_tab_completion.pl .. ok
>> t/020_cancel.pl .......... ok
>> All tests successful.
>> Files=3, Tests=169,  6 wallclock secs ( 0.06 usr  0.02 sys +  2.64 cusr
>> 0.99 csys =  3.71 CPU)
>> Result: PASS
>>
>> I wonder if you have something inconsistent in your locale
>> configuration.  What do you see from
>>
>> $ env | grep '^L[CA]'
>>
>
>  [pavel@localhost psql]$ env | grep '^L[CA]'
> LANG=cs_CZ.UTF-8
>
> Regards
>
> Pavel
>

Stranger things, but is LANG case sensitive, or formatted differently?

tom> $ LANG=cs_CZ.utf8 make installcheck
 you> LANG=cs_CZ.*UTF-8*



>
>
>>                         regards, tom lane
>>
>

  12. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-11T19:24:36Z

    Hi

>
>
> Stranger things, but is LANG case sensitive, or formatted differently?
>
> tom> $ LANG=cs_CZ.utf8 make installcheck
>  you> LANG=cs_CZ.*UTF-8*
>
>
I don't think so encoding is case sensitive - I am not sure, but minimally
ncurses applications works without any problems, and ncurses is very locale
sensitive

$ LANG=cs_CZ.utf8 make check

doesn't help

Regards

Pavel


>
>
>>
>>
>>>                         regards, tom lane
>>>
>>

  13. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-11T19:30:22Z

    Pavel Stehule <pavel.stehule@gmail.com> writes:
>> Stranger things, but is LANG case sensitive, or formatted differently?

> I don't think so encoding is case sensitive - I am not sure, but minimally
> ncurses applications works without any problems, and ncurses is very locale
> sensitive
> $ LANG=cs_CZ.utf8 make check
> doesn't help

Right, glibc is pretty forgiving about the spelling of the encoding
part of a locale identifier.  I did try Pavel's spelling cs_CZ.UTF-8
on my box, and that also works fine here.

It's hard to believe that any meaningful changes were made in this
area between F37 and F38, though.  I'm now wondering about relevant
packages being installed on one box and not the other...

			regards, tom lane

  14. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-11T20:37:52Z

    On Wed, May 10, 2023 at 12:59 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

> Hi
>
> When I remove this test, then all tests passed
>
> diff --git a/src/bin/psql/t/001_basic.pl b/src/bin/psql/t/001_basic.pl
> index 596746de17..631a1a7335 100644
> --- a/src/bin/psql/t/001_basic.pl
> +++ b/src/bin/psql/t/001_basic.pl
> @@ -353,11 +353,6 @@ psql_like(
>
>  # Check \watch
>  # Note: the interval value is parsed with locale-aware strtod()
> -psql_like(
> -   $node,
> -   sprintf('SELECT 1 \watch c=3 i=%g', 0.01),
> -   qr/1\n1\n1/,
> -   '\watch with 3 iterations');
>
>  # Check \watch errors
>  psql_fails_like(
>
> Can somebody repeat this testing of FC38?
>
> Regards
>
> Pavel
>
> Can you change the 0.01 to just 1 or 0?

I assume it will work then! (and better than a full removal)?

  15. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T00:08:30Z

    Kirk Wolak <wolakk@gmail.com> writes:
> Can you change the 0.01 to just 1 or 0?
> I assume it will work then! (and better than a full removal)?

IMO the point of that test is largely to exercise this locale-dependent
behavior, so I'm very unwilling to dumb it down to that extent.

What seems to be happening is that the spawned psql process is making
a different choice about what the LC_NUMERIC locale is than its parent
perl process did.  That seems like it might be a bug in itself, since
POSIX is pretty clear about how you're supposed to derive the locale
from the relevant environment variables.  But maybe it's Perl's bug?

			regards, tom lane

  16. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-12T04:02:34Z

    On Thu, May 11, 2023 at 8:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Kirk Wolak <wolakk@gmail.com> writes:
> > Can you change the 0.01 to just 1 or 0?
> > I assume it will work then! (and better than a full removal)?
>
> IMO the point of that test is largely to exercise this locale-dependent
> behavior, so I'm very unwilling to dumb it down to that extent.
>
> Sorry, I meant simply as opposed to deleting the test to get it to pass.


> What seems to be happening is that the spawned psql process is making
> a different choice about what the LC_NUMERIC locale is than its parent
> perl process did.  That seems like it might be a bug in itself, since
> POSIX is pretty clear about how you're supposed to derive the locale
> from the relevant environment variables.  But maybe it's Perl's bug?
>
>                         regards, tom lane
>

Did you try the print statement that Andrey asked Pavel to try?
Because it gave 2 different results for Pavel.  And Pavel's system has the
problem, but yours does not.

cat test.pl
use locale;
my $result = sprintf('SELECT 1 \watch c=3 i=%g', 0.01);
print ">>$result<<\n";

and when Pavel ran it, he got:

[pavel@localhost psql]$ perl test.pl
>>SELECT 1 \watch c=3 i=0,01<<
[pavel@localhost psql]$ LANG=C perl test.pl
>>SELECT 1 \watch c=3 i=0.01<<

Now I am curious what you get?

Because yours works.  This should identify the difference.

Kirk...

  17. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T04:14:20Z

    Kirk Wolak <wolakk@gmail.com> writes:
> Did you try the print statement that Andrey asked Pavel to try?

Yeah, and I get exactly the results I expect:

$ cat test.pl
use locale;
my $result = sprintf('SELECT 1 \watch c=3 i=%g', 0.01);
print ">>$result<<\n";
$ LANG=cs_CZ.utf8 perl test.pl
>>SELECT 1 \watch c=3 i=0,01<<
$ LANG=C perl test.pl
>>SELECT 1 \watch c=3 i=0.01<<

			regards, tom lane

  18. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-12T04:50:20Z

    On Fri, May 12, 2023 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Kirk Wolak <wolakk@gmail.com> writes:
> > Did you try the print statement that Andrey asked Pavel to try?
>
> Yeah, and I get exactly the results I expect:
>
> Your results MATCHED Pavels  (Hmm).  Piping ONE of those into psql should
fail, and the other one should work, right?

I know Pavel is Czech... So I have to Wonder...
Are both of you using the same Collation inside of PG? (Or did I miss that
the testing forces that setting?)

Kirk...

  19. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T05:45:39Z

    pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:

> On Fri, May 12, 2023 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Kirk Wolak <wolakk@gmail.com> writes:
>> > Did you try the print statement that Andrey asked Pavel to try?
>>
>> Yeah, and I get exactly the results I expect:
>>
>> Your results MATCHED Pavels  (Hmm).  Piping ONE of those into psql should
> fail, and the other one should work, right?
>
> I know Pavel is Czech... So I have to Wonder...
> Are both of you using the same Collation inside of PG? (Or did I miss that
> the testing forces that setting?)
>

The strange thing is hanging. Broken tests depending on locale are usual.
But I didn't remember hanging.

Regards

Pavel



> Kirk...
>

  20. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-12T06:19:54Z

    On Fri, May 12, 2023 at 1:46 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

> pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>
>> On Fri, May 12, 2023 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>>> Kirk Wolak <wolakk@gmail.com> writes:
>>> > Did you try the print statement that Andrey asked Pavel to try?
>>> ...
>>
>>
> The strange thing is hanging. Broken tests depending on locale are usual.
> But I didn't remember hanging.
>
> Regards
>
> Pavel
>

So, if you do psql -c "..."
with both of those \watch  instructions, do either one hang? (I am now
guessing "no")

I know that perl is using a special library to "remote control psql" (like
a pseudo terminal, I guess).
[I had to abort some of the perl testing in Windows because that perl
library didn't work with my psql in Windows]

Next, can you detect which process is hanging? (is it perl, the library,
psql, ?).

I would be curious now about the details of your perl install, and your
perl libraries...

  21. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T06:40:19Z

    pá 12. 5. 2023 v 8:20 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:

> On Fri, May 12, 2023 at 1:46 AM Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
>
>> pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>>
>>> On Fri, May 12, 2023 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>
>>>> Kirk Wolak <wolakk@gmail.com> writes:
>>>> > Did you try the print statement that Andrey asked Pavel to try?
>>>> ...
>>>
>>>
>> The strange thing is hanging. Broken tests depending on locale are usual.
>> But I didn't remember hanging.
>>
>> Regards
>>
>> Pavel
>>
>
> So, if you do psql -c "..."
> with both of those \watch  instructions, do either one hang? (I am now
> guessing "no")
>
> I know that perl is using a special library to "remote control psql" (like
> a pseudo terminal, I guess).
> [I had to abort some of the perl testing in Windows because that perl
> library didn't work with my psql in Windows]
>
> Next, can you detect which process is hanging? (is it perl, the library,
> psql, ?).
>

It hangs in perl

but now I found there is dependency on PSQL_PAGER setting

it started pager in background, I had lot of zombie pspg processes

Unfortunately, when I unset this variable, the test hangs still

here is backtrace

Missing separate debuginfos, use: dnf debuginfo-install
perl-interpreter-5.36.1-496.fc38.x86_64
(gdb) bt
#0  0x00007fbbc1129ade in select () from /lib64/libc.so.6
#1  0x00007fbbc137363b in Perl_pp_sselect () from /lib64/libperl.so.5.36
#2  0x00007fbbc1317958 in Perl_runops_standard () from
/lib64/libperl.so.5.36
#3  0x00007fbbc128259d in perl_run () from /lib64/libperl.so.5.36
#4  0x000056392bd9034a in main ()

It is waiting on reading from pipe probably

psql is living too, and it is waiting too

Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f071740bc37 in wait4 () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.37-4.fc38.x86_64 ncurses-libs-6.4-3.20230114.fc38.x86_64
readline-8.2-3.fc38.x86_64
(gdb) bt
#0  0x00007f071740bc37 in wait4 () from /lib64/libc.so.6
#1  0x00007f07173a9a10 in _IO_proc_close@@GLIBC_2.2.5 () from
/lib64/libc.so.6
#2  0x00007f07173b51e9 in __GI__IO_file_close_it () from /lib64/libc.so.6
#3  0x00007f07173a79fb in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
#4  0x0000000000406be4 in do_watch (query_buf=query_buf@entry=0x5ae540,
sleep=sleep@entry=0.01, iter=0, iter@entry=3) at command.c:5348
#5  0x00000000004087a5 in exec_command_watch
(scan_state=scan_state@entry=0x5ae490,
active_branch=active_branch@entry=true, query_buf=query_buf@entry=0x5ae540,
previous_buf=previous_buf@entry=0x5ae560) at command.c:2875
#6  0x000000000040d4ba in exec_command (previous_buf=0x5ae560,
query_buf=0x5ae540, cstack=0x5ae520, scan_state=0x5ae490, cmd=0x5ae9a0
"watch") at command.c:413
#7  HandleSlashCmds (scan_state=scan_state@entry=0x5ae490,
cstack=cstack@entry=0x5ae520, query_buf=0x5ae540, previous_buf=0x5ae560) at
command.c:230

I am not sure, it is still doesn't work but probably there are some
dependencies on my setting

PSQL_PAGER and PSQL_WATCH_PAGER

so this tests fails due my setting

[pavel@localhost postgresql.master]$ set |grep PSQL
PSQL_PAGER='pspg -X'
PSQL_WATCH_PAGER='pspg -X --stream'

Regards

Pavel










>
> I would be curious now about the details of your perl install, and your
> perl libraries...
>
>
>
>

  22. Re: psql tests hangs

    Kirk Wolak <wolakk@gmail.com> — 2023-05-12T07:00:05Z

    On Fri, May 12, 2023 at 2:40 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

> pá 12. 5. 2023 v 8:20 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>
>> On Fri, May 12, 2023 at 1:46 AM Pavel Stehule <pavel.stehule@gmail.com>
>> wrote:
>>
>>> pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>>>
>>>> On Fri, May 12, 2023 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>
>>>>> Kirk Wolak <wolakk@gmail.com> writes:
>>>>> > Did you try the print statement that Andrey asked Pavel to try?
>>>>> ...
>>>>
>>>>
>>> The strange thing is hanging. Broken tests depending on locale are
>>> usual. But I didn't remember hanging.
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>
>> So, if you do psql -c "..."
>> with both of those \watch  instructions, do either one hang? (I am now
>> guessing "no")
>>
>> I know that perl is using a special library to "remote control psql"
>> (like a pseudo terminal, I guess).
>> [I had to abort some of the perl testing in Windows because that perl
>> library didn't work with my psql in Windows]
>>
>> Next, can you detect which process is hanging? (is it perl, the library,
>> psql, ?).
>>
>
> It hangs in perl
>
> but now I found there is dependency on PSQL_PAGER setting
>
> it started pager in background, I had lot of zombie pspg processes
>
> Unfortunately, when I unset this variable, the test hangs still
>
> here is backtrace
>
> Missing separate debuginfos, use: dnf debuginfo-install
> perl-interpreter-5.36.1-496.fc38.x86_64
> (gdb) bt
> #0  0x00007fbbc1129ade in select () from /lib64/libc.so.6
> #1  0x00007fbbc137363b in Perl_pp_sselect () from /lib64/libperl.so.5.36
> #2  0x00007fbbc1317958 in Perl_runops_standard () from
> /lib64/libperl.so.5.36
> #3  0x00007fbbc128259d in perl_run () from /lib64/libperl.so.5.36
> #4  0x000056392bd9034a in main ()
>
> It is waiting on reading from pipe probably
>
> psql is living too, and it is waiting too
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 0x00007f071740bc37 in wait4 () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install
> glibc-2.37-4.fc38.x86_64 ncurses-libs-6.4-3.20230114.fc38.x86_64
> readline-8.2-3.fc38.x86_64
> (gdb) bt
> #0  0x00007f071740bc37 in wait4 () from /lib64/libc.so.6
> #1  0x00007f07173a9a10 in _IO_proc_close@@GLIBC_2.2.5 () from
> /lib64/libc.so.6
> #2  0x00007f07173b51e9 in __GI__IO_file_close_it () from /lib64/libc.so.6
> #3  0x00007f07173a79fb in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
> #4  0x0000000000406be4 in do_watch (query_buf=query_buf@entry=0x5ae540,
> sleep=sleep@entry=0.01, iter=0, iter@entry=3) at command.c:5348
> #5  0x00000000004087a5 in exec_command_watch (scan_state=scan_state@entry=0x5ae490,
> active_branch=active_branch@entry=true, query_buf=query_buf@entry=0x5ae540,
> previous_buf=previous_buf@entry=0x5ae560) at command.c:2875
> #6  0x000000000040d4ba in exec_command (previous_buf=0x5ae560,
> query_buf=0x5ae540, cstack=0x5ae520, scan_state=0x5ae490, cmd=0x5ae9a0
> "watch") at command.c:413
> #7  HandleSlashCmds (scan_state=scan_state@entry=0x5ae490,
> cstack=cstack@entry=0x5ae520, query_buf=0x5ae540, previous_buf=0x5ae560)
> at command.c:230
>
> I am not sure, it is still doesn't work but probably there are some
> dependencies on my setting
>
> PSQL_PAGER and PSQL_WATCH_PAGER
>
> so this tests fails due my setting
>
> [pavel@localhost postgresql.master]$ set |grep PSQL
> PSQL_PAGER='pspg -X'
> PSQL_WATCH_PAGER='pspg -X --stream'
>
> Regards
>
> Pavel
>
>
Ummm... We are testing PSQL \watch  and you potentially have a
PSQL_WATCH_PAGER that is kicking in?
By chance does that attempt to read/process/understand the \watch ?
Also, if it is interfering with the stream, that would explain it.  The
perl library is trying to "control" psql.
If it ends up talking to you instead... All bets are off, imo.  I don't
know enough about PSQL_WATCH_PAGER.

Now I would be curious if you changed the test from
SELECT 1 \watch c=3 0.01

to
SELECT 1 \watch 0.01

because that should work.  Then I would test
SELECT \watch 0.01 c=3

If you are trying to parse the watch at all, that could break.  Then your
code might be trying to "complain",
and then that is screwing up the planned interaction (Just Guessing).

Kirk...

  23. Re: psql tests hangs

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2023-05-12T07:46:51Z

    On 2023-May-12, Pavel Stehule wrote:

> It hangs in perl

I wonder if "hanging" actually means that it interpreted the sleep time
as a very large integer, so it's just sleeping for a long time.

About the server locale, note that the ->new() call explicitly requests
the C locale -- it's only psql that is using the Czech locale.
Supposedly, the Perl code should also be using the Czech locale, so the
sprintf('%g') should be consistent with what psql \watch expects.
However, you cannot ask the server to be consistent with that -- say, if
you hypothetically tried to use "to_char(9D99)" and \gset that to use as
\watch argument, it wouldn't work, because that'd use the server's C
locale, not Czech.  (I know because I tried.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"

  24. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T08:31:01Z

    pá 12. 5. 2023 v 9:46 odesílatel Alvaro Herrera <alvherre@alvh.no-ip.org>
napsal:

> On 2023-May-12, Pavel Stehule wrote:
>
> > It hangs in perl
>
> I wonder if "hanging" actually means that it interpreted the sleep time
> as a very large integer, so it's just sleeping for a long time.
>

There is some interaction with pspg in stream mode

The probable scenario

It is starting pspg due to my setting PSQL_WATCH_PAGER. pspg is waiting on
quit command, or on pipe ending. Quit command cannot to come because it is
not on tty, so it is dead lock

I can write to safeguard the fast ending on pspg when it is in stream mode,
and tty is not available.

And generally, the root perl should to reset PSQL_WATCH_PAGER env variable
before executing psql. Probably it does with PSQL_PAGER, and maybe with
PAGER.

Regards

Pavel


>
> About the server locale, note that the ->new() call explicitly requests
> the C locale -- it's only psql that is using the Czech locale.
> Supposedly, the Perl code should also be using the Czech locale, so the
> sprintf('%g') should be consistent with what psql \watch expects.
> However, you cannot ask the server to be consistent with that -- say, if
> you hypothetically tried to use "to_char(9D99)" and \gset that to use as
> \watch argument, it wouldn't work, because that'd use the server's C
> locale, not Czech.  (I know because I tried.)
>
> --
> Álvaro Herrera        Breisgau, Deutschland  —
> https://www.EnterpriseDB.com/
> "Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"
>

  25. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T12:39:41Z

    pá 12. 5. 2023 v 10:31 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

>
>
> pá 12. 5. 2023 v 9:46 odesílatel Alvaro Herrera <alvherre@alvh.no-ip.org>
> napsal:
>
>> On 2023-May-12, Pavel Stehule wrote:
>>
>> > It hangs in perl
>>
>> I wonder if "hanging" actually means that it interpreted the sleep time
>> as a very large integer, so it's just sleeping for a long time.
>>
>
> There is some interaction with pspg in stream mode
>
> The probable scenario
>
> It is starting pspg due to my setting PSQL_WATCH_PAGER. pspg is waiting on
> quit command, or on pipe ending. Quit command cannot to come because it is
> not on tty, so it is dead lock
>
> I can write to safeguard the fast ending on pspg when it is in stream
> mode, and tty is not available.
>
> And generally, the root perl should to reset PSQL_WATCH_PAGER env variable
> before executing psql. Probably it does with PSQL_PAGER, and maybe with
> PAGER.
>

with last change in pspg, this tests fails as "expected"

aster/src/bin/psql/../../../src/test/regress/pg_regress' /usr/bin/prove -I
../../../src/test/perl/ -I .  t/*.pl
# +++ tap check in src/bin/psql +++
t/001_basic.pl ........... 59/?
#   Failed test '\watch with 3 iterations: no stderr'
#   at t/001_basic.pl line 356.
#          got: 'stream mode can be used only in interactive mode (tty is
not available)'
#     expected: ''

#   Failed test '\watch with 3 iterations: matches'
#   at t/001_basic.pl line 356.
#                   ''
#     doesn't match '(?^l:1\n1\n1)'
# Looks like you failed 2 tests of 80.
t/001_basic.pl ........... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/80 subtests
t/010_tab_completion.pl .. ok
t/020_cancel.pl .......... ok

Test Summary Report
-------------------
t/001_basic.pl         (Wstat: 512 (exited 2) Tests: 80 Failed: 2)
  Failed tests:  69-70
  Non-zero exit status: 2
Files=3, Tests=169,  7 wallclock secs ( 0.16 usr  0.03 sys +  3.31 cusr
 1.31 csys =  4.81 CPU)
Result: FAIL
make: *** [Makefile:87: check] Chyba 1

Regards

Pavel

>
> Regards
>
> Pavel
>
>
>>
>> About the server locale, note that the ->new() call explicitly requests
>> the C locale -- it's only psql that is using the Czech locale.
>> Supposedly, the Perl code should also be using the Czech locale, so the
>> sprintf('%g') should be consistent with what psql \watch expects.
>> However, you cannot ask the server to be consistent with that -- say, if
>> you hypothetically tried to use "to_char(9D99)" and \gset that to use as
>> \watch argument, it wouldn't work, because that'd use the server's C
>> locale, not Czech.  (I know because I tried.)
>>
>> --
>> Álvaro Herrera        Breisgau, Deutschland  —
>> https://www.EnterpriseDB.com/
>> "Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"
>>
>

  26. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T13:26:27Z

    Pavel Stehule <pavel.stehule@gmail.com> writes:
> And generally, the root perl should to reset PSQL_WATCH_PAGER env variable
> before executing psql. Probably it does with PSQL_PAGER, and maybe with
> PAGER.

Oh!  AFAICS, we don't do any of those things, but I agree it seems like
a good idea.  Can you confirm that if you unset PSQL_WATCH_PAGER then
the test passes for you?

			regards, tom lane

  27. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T15:18:42Z

    pá 12. 5. 2023 v 15:26 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > And generally, the root perl should to reset PSQL_WATCH_PAGER env
> variable
> > before executing psql. Probably it does with PSQL_PAGER, and maybe with
> > PAGER.
>
> Oh!  AFAICS, we don't do any of those things, but I agree it seems like
> a good idea.  Can you confirm that if you unset PSQL_WATCH_PAGER then
> the test passes for you?
>

yes, I tested it now, and unset  PSQL_WATCH_PAGER fixed this issue.

Regards

Pavel


>                         regards, tom lane
>

  28. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T15:50:53Z

    Pavel Stehule <pavel.stehule@gmail.com> writes:
> pá 12. 5. 2023 v 15:26 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> Oh!  AFAICS, we don't do any of those things, but I agree it seems like
>> a good idea.  Can you confirm that if you unset PSQL_WATCH_PAGER then
>> the test passes for you?

> yes, I tested it now, and unset  PSQL_WATCH_PAGER fixed this issue.

OK.  So after looking at this a bit, the reason PAGER and PSQL_PAGER
don't cause us any problems in the test environment is that they are
not honored unless isatty(fileno(stdin)) && isatty(fileno(stdout)).
It seems to me that it's a bug that there is no such check before
using PSQL_WATCH_PAGER.  Is there actually any defensible reason
for that?

I think we do need to clear out all three variables in
Cluster::interactive_psql.  But our regular psql tests shouldn't
be at risk here.

			regards, tom lane

  29. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T16:12:56Z

    pá 12. 5. 2023 v 17:50 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > pá 12. 5. 2023 v 15:26 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
> >> Oh!  AFAICS, we don't do any of those things, but I agree it seems like
> >> a good idea.  Can you confirm that if you unset PSQL_WATCH_PAGER then
> >> the test passes for you?
>
> > yes, I tested it now, and unset  PSQL_WATCH_PAGER fixed this issue.
>
> OK.  So after looking at this a bit, the reason PAGER and PSQL_PAGER
> don't cause us any problems in the test environment is that they are
> not honored unless isatty(fileno(stdin)) && isatty(fileno(stdout)).
> It seems to me that it's a bug that there is no such check before
> using PSQL_WATCH_PAGER.  Is there actually any defensible reason
> for that?
>

Theoretically, we can write tests for these features, and then stdout,
stdin may not be tty.

Except for testing, using pager in non-interactive mode makes no sense.

Regards

Pavel



> I think we do need to clear out all three variables in
> Cluster::interactive_psql.  But our regular psql tests shouldn't
> be at risk here.
>
>                         regards, tom lane
>

  30. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T17:28:04Z

    Pavel Stehule <pavel.stehule@gmail.com> writes:
> pá 12. 5. 2023 v 17:50 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> OK.  So after looking at this a bit, the reason PAGER and PSQL_PAGER
>> don't cause us any problems in the test environment is that they are
>> not honored unless isatty(fileno(stdin)) && isatty(fileno(stdout)).
>> It seems to me that it's a bug that there is no such check before
>> using PSQL_WATCH_PAGER.  Is there actually any defensible reason
>> for that?

> Theoretically, we can write tests for these features, and then stdout,
> stdin may not be tty.

Well, you'd test using pty's, so that psql thinks it's talking to a
terminal.  That's what we're doing now to test tab completion,
for example.

> Except for testing, using pager in non-interactive mode makes no sense.

Agreed.  Let's solve this by inserting isatty tests in psql, rather
than hacking the test environment.

			regards, tom lane

  31. Re: psql tests hangs

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-05-12T19:08:47Z

    I wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> Except for testing, using pager in non-interactive mode makes no sense.

> Agreed.  Let's solve this by inserting isatty tests in psql, rather
> than hacking the test environment.

Here's a proposed patch for this.  I noticed that another memo the
PSQL_WATCH_PAGER patch had not gotten was the lesson learned in
commit 18f8f784c, namely that it's a good idea to ignore empty
or all-blank settings.

			regards, tom lane

  32. Re: psql tests hangs

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-05-12T19:17:00Z

    pá 12. 5. 2023 v 21:08 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> I wrote:
> > Pavel Stehule <pavel.stehule@gmail.com> writes:
> >> Except for testing, using pager in non-interactive mode makes no sense.
>
> > Agreed.  Let's solve this by inserting isatty tests in psql, rather
> > than hacking the test environment.
>
> Here's a proposed patch for this.  I noticed that another memo the
> PSQL_WATCH_PAGER patch had not gotten was the lesson learned in
> commit 18f8f784c, namely that it's a good idea to ignore empty
> or all-blank settings.
>

+1

Pavel


>                         regards, tom lane
>
>