psql tests hangs

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

ú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.

ú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

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:
/messages/by-id/CAAhFRxiZ2-n_L1ErMm9AZjgmUK=qS6VHb+0SaMn8sqqbhF7How@mail.gmail.com

Discussion:
/messages/by-id/CAPmGK15FuPVGx3TGHKShsbPKKtF1y58-ZLcKoxfN-nqLj1dZ=g@mail.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

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

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.

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

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

č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

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*

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

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

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)?

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

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...

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

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...

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

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...