tuhaihe commented on PR #731:
URL: https://github.com/apache/cloudberry/pull/731#issuecomment-2538709529
> Getting closer! When running manually, I would run with one of the
following. The first diff explicitly expects the orca optimizer to be set on
(regardless of it being on by default).
>
> With Orca query optimizer on:
>
> ```
> PGOPTIONS='-c optimizer=on' make installcheck
> ```
>
> With Orca query optimizer off:
>
> ```
> PGOPTIONS='-c optimizer=off' make installcheck
> ```
Thanks @edespino! It works.
I ran the following two commands:
1. No errors
```
$ PGCLIENTENCODING=UTF8 PGOPTIONS='-c optimizer=on' make -C src/test
installcheck-cbdb-parallel
...
=======================
All 259 tests passed.
=======================
make[1]: Leaving directory '/home/gpadmin/cloudberry/src/test/isolation2'
make: Leaving directory '/home/gpadmin/cloudberry/src/test'
```
2. Still has the encoding errors for latin1
```
$ PGCLIENTENCODING=UTF8 PGOPTIONS='-c optimizer=on' make installcheck
...
========================
2 of 659 tests failed.
========================
[gpadmin@cdw cloudberry]$ cat
/home/gpadmin/cloudberry/src/test/regress/regression.diffs
diff -I HINT: -I CONTEXT: -I GP_IGNORE: -U3
/home/gpadmin/cloudberry/src/test/regress/expected/gpcopy_encoding.out
/home/gpadmin/cloudberry/src/test/regress/results/gpcopy_encoding.out
--- /home/gpadmin/cloudberry/src/test/regress/expected/gpcopy_encoding.out
2024-12-12 03:03:35.691378647 -0800
+++ /home/gpadmin/cloudberry/src/test/regress/results/gpcopy_encoding.out
2024-12-12 03:03:35.693378680 -0800
@@ -21,7 +21,7 @@
copy enctest to '/tmp/enctest_utf_to_latin1-1' encoding 'latin1';
set client_encoding='latin1';
copy enctest to stdout;
-�
+�
copy enctest to '/tmp/enctest_utf_to_latin1-2';
-- Connect to 'latin1' database, and load back the files we just created.
-- This is to check that they were created correctly, and that the ENCODING
diff -I HINT: -I CONTEXT: -I GP_IGNORE: -U3
/home/gpadmin/cloudberry/src/test/regress/expected/dispatch_encoding.out
/home/gpadmin/cloudberry/src/test/regress/results/dispatch_encoding.out
--- /home/gpadmin/cloudberry/src/test/regress/expected/dispatch_encoding.out
2024-12-12 03:06:09.112219102 -0800
+++ /home/gpadmin/cloudberry/src/test/regress/results/dispatch_encoding.out
2024-12-12 03:06:09.114219140 -0800
@@ -55,14 +55,16 @@
select raise_error(t) from enctest;
ERROR: raise_error called on "funny char Ä"
+CONTEXT: PL/pgSQL function raise_error(text) line 3 at RAISE
-- now do it again with latin1
set client_encoding='latin1';
select raise_notice(t) from enctest;
-NOTICE: raise_notice called on "funny char �"
+NOTICE: raise_notice called on "funny char �"
raise_notice
--------------
(1 row)
select raise_error(t) from enctest;
-ERROR: raise_error called on "funny char �"
+ERROR: raise_error called on "funny char �"
+CONTEXT: PL/pgSQL function raise_error(text) line 3 at RAISE
```
For now, I can continue testing by setting up the correct encoding
environment for Latin1. However, this issue doesn’t seem critical since our
CI/CD pipeline has passed successfully.
Would it be possible to merge this PR now, or would you prefer that I ensure
all tests pass locally before proceeding? Personally, I lean towards merging
the PR now, as the failed tests are limited to my local environment settings.
Otherwise, with new PRs being introduced, I would need to rebase multiple times
to address potential failures caused by the latest commits.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
