cannot free environment handle -- with some CLOB

[sebasmannem]

When copying data from fdw tables into local tables, we run into issues such as these:

The following occurs 5 times:

2025-10-30 13:32:11.979 CET [1530640] FATAL:  cannot free environment handle
2025-10-30 13:32:11.979 CET [1530640] DETAIL:  SQLSTATE = HY010  SQLCODE = -99999
        line=47
        file=source/db2FreeEnvHdl.c
        [IBM][CLI Driver] CLI0125E  Function sequence error. SQLSTATE=HY010

After which we have

2025-10-30 13:32:19.953 CET [1528723] LOG:  server process (PID 1530675) was terminated by signal 11: Segmentation fault
2025-10-30 13:32:19.953 CET [1528723] DETAIL:  Failed process was running: insert into someschema.sometbl (col1, col2, ...
2025-10-30 13:32:19.953 CET [1528723] LOG:  terminating any other active server processes

Over 1500 tables, this occurs for about 15 tables, and they all seem to work fine when leaving out the CLOB fields

[sebasmannem]

Unfortunately we cannot share the schema or data, but feel free to bring us any questions regarding these columns.

[temuenz]

I am guessing this is due to the tables containing nulls in CLOB columns. Please, check if my last fix that fixes null values in *LOB columns, also fixes this issue.

[sebasmannem]

Your latest fix has resolved a lot of issues, but we still have this issue.
It seems to be the result of every query using the fdw (also tables without CLOB).
We do get data though?

[temuenz]

I recognized that there still is this problem. I will be working on this asap.

[sebasmannem]

You are awesome.

Some extra logging:

[db2inst1@server ~]$ cat issue1.txt
2025-11-04 14:56:03.963 CET [3809258] LOG:  starting PostgreSQL 17.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), 64-bit
2025-11-04 14:56:03.964 CET [3809258] LOG:  listening on IPv6 address "::1", port 5433
2025-11-04 14:56:03.965 CET [3809258] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2025-11-04 14:56:03.969 CET [3809258] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
2025-11-04 14:56:03.977 CET [3809265] LOG:  database system was shut down at 2025-11-04 14:56:03 CET
2025-11-04 14:56:03.985 CET [3809258] LOG:  database system is ready to accept connections
 
[db2inst1@server ~]$ psql -p 5433 -h /tmp poseidon
psql (17.6)
Type "help" for help.
 
mydb=# IMPORT FOREIGN SCHEMA "BANK" FROM SERVER db24mike2 INTO f_db2_bank;
IMPORT FOREIGN SCHEMA
mydb=# \q
[db2inst1@server ~]$ cat /pgdata/db2/cl1/log/postgresql-Tue.log
2025-11-04 14:56:03.963 CET [3809258] LOG:  starting PostgreSQL 17.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), 64-bit
2025-11-04 14:56:03.964 CET [3809258] LOG:  listening on IPv6 address "::1", port 5433
2025-11-04 14:56:03.965 CET [3809258] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2025-11-04 14:56:03.969 CET [3809258] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
2025-11-04 14:56:03.977 CET [3809265] LOG:  database system was shut down at 2025-11-04 14:56:03 CET
2025-11-04 14:56:03.985 CET [3809258] LOG:  database system is ready to accept connections
2025-11-04 14:57:16.862 CET [3809577] FATAL:  cannot free environment handle
2025-11-04 14:57:16.862 CET [3809577] DETAIL:  SQLSTATE = HY010  SQLCODE = -99999
        line=47
        file=source/db2FreeEnvHdl.c
        [IBM][CLI Driver] CLI0125E  Function sequence error. SQLSTATE=HY010

[sebasmannem]

I have an idea, where every PR would spin up a docker-compose env with:

• a DB2 container, with a demo schema, one table per type, one col, and then some values e.a. NULL, small data, large CLOB, etc.
• a PostgreSQL container with Foreign Data wrapper built, where we get the schema
• a container with a test image, which checks if the FDW retrieves data as expected

Shall I create a PR? I think it would speed up dev hugely.
And I would be happy to actually contribute if we have that...

[temuenz]

I would welcome that greatly. The lack of proper testing is becoming obvious.

[temuenz]

I found one flaw in freeing the connection handle. That is now fixed, but still the environment is failing upon free. I am a bit lost as to why.
The implications might be neglegible, since that all only happens when you quit the psql console or you application disconnects from PG. On Db2 the connection is already dropped at that time.
Still I'd want to understand why this is happening.

[temuenz]

This has been a tricky one. db2AllocConHandle has a parameter nls_lang. When it is used, the function does allocate another connection but it does not completely initialize that and it does not put that handle into the internal connection handle chain.

In db2GetSession I thought providing the nls_lang in the first call when there is an envp given, was a good idea. Well, it wasn't. Using NULL there fixed the issue since the already existing connection was used and no other one allocated.

With that at the end, the con handle was properly released which then also allowed the env handle to be properly released.