Closed
Description
Building 16.00.0006 against PG17.0, I'm getting this regression test diff:
*** ./expected/descrec.out Fri Sep 27 11:28:28 2024
--- results/descrec.out Fri Sep 27 11:42:56 2024
***************
*** 19,25 ****
-- Column 3 --
SQL_DESC_NAME: col3
SQL_DESC_TYPE: 12
! SQL_DESC_OCTET_LENGTH: 40
SQL_DESC_PRECISION: 0
SQL_DESC_SCALE: 0
SQL_DESC_NULLABLE: 0
--- 19,25 ----
-- Column 3 --
SQL_DESC_NAME: col3
SQL_DESC_TYPE: 12
! SQL_DESC_OCTET_LENGTH: 10
SQL_DESC_PRECISION: 0
SQL_DESC_SCALE: 0
SQL_DESC_NULLABLE: 0
Could you have a look?
Metadata
Metadata
Assignees
Labels
No labels
Activity
davecramer commentedon Sep 27, 2024
hmmm ok, thanks, I'll look into this right now
davecramer commentedon Sep 27, 2024
Interestingly enough it passes https://github.com/postgresql-interfaces/psqlodbc/pull/52/checks. I wonder if this is due to needing version 17?
Hunaid2000 commentedon Sep 30, 2024
Which OS?
I built psqlodbc (tag: REL-16_00_0006) with pg17 and pg16.4 binaries on Windows, all regressions are good.
df7cb commentedon Oct 4, 2024
17.00.0002 still fails here (Debian unstable, PG 17.0) in the same way.
@davecramer from our chat last week, I thought you had an idea how to tackle it and didn't follow up here. Do you need any more details?
davecramer commentedon Oct 4, 2024
@df7cb I thought I sent you the query that the driver does.
df7cb commentedon Oct 4, 2024
Running that against 16 and 17 gives the same results (modulo different pg_temp_NN nspname and table oid).
There are already two expected output files in test/expected/descrec.out and test/expected/descrec_1.out with this difference:
I haven't yet figured out what that length means, but perhaps "10" is another valid output besides 20 and 40?
(I hate pg_regress for making it hard to put comments on _1.out alternate output files.)
davecramer commentedon Oct 4, 2024
So looking at the results of the query COL3 is 14, which is 20 decimal, no?
Hunaid2000 commentedon Oct 5, 2024
It basically depends on client encoding, I guess.
I get 20 on Windows and 40 on Ubuntu. The length is set in
pgtype_attr_buffer_length
function.psqlodbc/pgtypes.c
Lines 1098 to 1118 in 59728b9
It depends on
coef = conn->mb_maxbyte_per_char;
which is set on the line629
in this block.psqlodbc/connection.c
Lines 615 to 632 in 59728b9
In case of Ubuntu:
psqlodbc/multibyte.c
Lines 211 to 236 in 59728b9
which maps to 4 here:
pg_mb_maxlen(self->ccsc);
. As a result, we get 10 * 4 = 40.For Windows, I believe its just
prec * WCLEN
so 10 * 2 = 20.@df7cb In your case, I guess
pg_mb_maxlen
returns 1.df7cb commentedon Oct 29, 2024
Something is definitely wrong in this area. I've now added yet another descrec_2.out file to accept
10
as valid and the build passes on amd64, but it then fails on s390x (which is big endian):... which looks suspiciously like an endianess problem.
df7cb commentedon Feb 27, 2025
Fwiw, I tried digging into this, but couldn't find the problem. I bet it is somewhere where the
.buflen
value gets assigned to one of these pointers, but I don't know which codepath is the bad one and they all look slightly different.I'll just ignore this test altogether on Debian, but this is clearly a bug, both on big and (imho) on little endian.
Fix GetDescRec on big-endian architectures
Add expected output file for descrec test in C locale
Fix GetDescRec on big-endian architectures (#130)
Add expected output file for descrec test in C locale (#131)