网站下载的软件在哪里找的到,找人做短视频网站,怎么提高网站转化率,高校建设主流网站【GaussDB】排查ARM64环境上gaussdb的python驱动(psycopg3)coredump的问题 没想到这个系列还会有第五篇。 背景 通过前几篇的操作#xff0c;我已经完全打通了airflow-sqlalchemy-GaussDB-sqlalchemy-gaussdb(psycopg3)-libpq(gaussdb)-GaussDB数据库。…【GaussDB】排查ARM64环境上gaussdb的python驱动(psycopg3)coredump的问题没想到这个系列还会有第五篇。背景通过前几篇的操作我已经完全打通了airflow-sqlalchemy-GaussDB-sqlalchemy-gaussdb(psycopg3)-libpq(gaussdb)-GaussDB数据库。可是当相同的操作流程放到客户的服务器上执行时python进程却发生了coredump。基础分析首先我确认了该环境中LD_LIBRARY_PATH里已经把GaussDB的libpq配置到了最前面而且也删除了操作系统里自带的libpq并且确认了使用的libpq是arm64版本的和这个服务器是匹配的但依旧coredump。由于我本地没有arm环境可以用于复现测试于是我用了华为云开发者空间的云开发空间里启动了个免费的开发容器并且在本地的vscode里通过Huawei Developer Space插件连上了这个容器方便使用AI来排查问题。接下来先按上一篇文章把airflow搭好配上连接串由于这个环境暂时没有GaussDB数据库可以连我就先随便写了个连接串如果正常就应该报错连接失败异常就应该coredump。结果在这个环境中的确复现了coredump接下来就是编写小型化用例编写通过sqlalchemy连接gaussdb的例子(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# cat test2.pyimportsqlalchemy as sa enginesa.create_engine(gaussdbgaussdb://username:password127.0.0.1:3333/database_name)with engine.connect()as conn: resultconn.execute(sa.text(SELECT 1))print(result.scalar())(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]#(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# python test2.pySegmentation fault(core dumped)(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]#coredump了再编写直接使用python驱动连接gaussdb的例子(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# cat test1.py#!/usr/bin/env python3importargparseimportosimportsys def main()-int: try:importgaussdb except Exception as exc: print(f[ERROR] Failed to import gaussdb: {exc})return3print([INFO] gaussdb module:, getattr(gaussdb,__file__,unknown))print([INFO] gaussdb version:, getattr(gaussdb,__version__,unknown))connNone try: conngaussdb.connect(host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword,connect_timeout10)with conn.cursor()as cur: cur.execute(select 1)rowcur.fetchone()print([OK] Connection succeeded, query result:, row)return0except Exception as exc: print(f[ERROR] Connection/query failed: {exc})return1finally:ifconn is not None: try: conn.close()except Exception: passif__name____main__:sys.exit(main())(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# python test1.py[INFO]gaussdb module: /workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/__init__.py[INFO]gaussdb version:1.0.4 Segmentation fault(core dumped)(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]#也coredump了直接写个c程序调用libpq(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# cat test_pq.c#include stdio.h#include stdlib.h#include libpq-fe.hintmain(){// 连接字符串请根据实际情况修改数据库名、用户名、密码和主机 PGconn *connPQconnectdb(dbnamepostgres userpostgres passwordsecret hostlocalhost);if(PQstatus(conn)!CONNECTION_OK){fprintf(stderr,连接失败: %s, PQerrorMessage(conn));PQfinish(conn);exit(1);}printf(成功连接到 PostgreSQL\n);PQfinish(conn);return0;}(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# gcc -o test_pq test_pq.c -I/workspace/test_gaussdb/gaussdb-libpq/include -L/workspace/test_gaussdb/gaussdb-libpq/lib -lpq(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]# ./test_pq连接失败: could not connect to server: Operation nowinprogress Is the server running onhostlocalhost(::1)and accepting TCP/IP connections on port5432? could not connect to server: Operation nowinprogress Is the server running onhostlocalhost(127.0.0.1)and accepting TCP/IP connections on port5432?(.env311)[rootae910d8786f844c4b317045140860809 test_gaussdb]#正常执行没有coredump。但这些代码在我自己的x86_64机器上执行都是没有问题而且我自己还试了两台服务器而客户的服务器和这个华为云的云开发环境一样都是ARM64的均出现了coredump的问题。目前暂且认为CPU架构是一个差异点。AI分析接着就让AI开始分析了我在vscode里选了gpt-5.3-codexUser: 检查一下为什么我编写C调用libpq不会coredump但是使用python调用gaussdb驱动会coredump,驱动源码在gaussdb-python目录(.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# ./test_pq 连接失败: could not connect to server: Operation now in progress Is the server running on host localhost (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Operation now in progress Is the server running on host localhost (127.0.0.1) and accepting TCP/IP connections on port 5432? (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# python test1.py [INFO] gaussdb module: /workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/__init__.py [INFO] gaussdb version: 1.0.4 Segmentation fault (core dumped) (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]# ll total 40 drwxr-x--- 4 root root 4096 Mar 4 09:09 gaussdb-libpq drwxr-x--- 11 root root 4096 Mar 4 09:20 gaussdb-python drwxr-x--- 7 root root 4096 Mar 4 09:11 GaussDB-sqlalchemy -rw-r----- 1 root root 1014 Mar 4 09:17 test1.py -rw-r----- 1 root root 231 Mar 4 09:10 test2.py -rwxr-x--- 1 root root 71192 Mar 4 09:32 test_pq -rw-r----- 1 root root 504 Mar 4 09:28 test_pq.c (.env311) [rootae910d8786f844c4b317045140860809 test_gaussdb]#GitHub Copilot: 我先快速定位崩溃点会先看test1.py和gaussdb-python里导入路径、底层.so加载逻辑再直接复现一次并抓 Python 的 faulthandler/gdb 回溯确认是驱动初始化崩溃还是连接阶段崩溃。然后给你一个可执行的修复方案。Created 4 todos我先并行读取关键文件test1.py、test2.py、test_pq.c以及驱动初始化入口目的是判断崩溃发生在import还是connect。Read [](file:///workspace/test_gaussdb/test1.py)Read [](file:///workspace/test_gaussdb/test2.py)Read [](file:///workspace/test_gaussdb/test_pq.c)Searched for files matching**/test_gaussdb/gaussdb-python/gaussdb/gaussdb/**, 20 matchesSearched for regeximport gaussdb|from gaussdb|ctypes|CDLL|PyInit|_psycopg|libpq(**/test_gaussdb/gaussdb-python/**), 200 results已经确认驱动会优先加载 C 扩展实现下一步我读取init.py、init.py 和 _cmodule.py 来确认加载顺序并判断为何import阶段就段错误。Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/init.py)Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/init.py)Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/_cmodule.py)现在我直接做三组复现默认导入、强制GAUSSDB_IMPLpython、再打印ldd依赖目标是确认是否gaussdb_c二进制扩展与系统libpq/OpenSSLABI 冲突导致段错误。Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate python -X faulthandler -c “import gaussdb; print(‘ok’, gaussdb.version)”Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate GAUSSDB_IMPLpython python -X faulthandler -c “import gaussdb; import gaussdb.pq as pq; print(‘ok’, gaussdb.version, pq.impl, pq.version())”Ran terminal command: cd /workspace/test_gaussdb find gaussdb-python -name “_gaussdb.so” -o -name “gaussdb_c.so” | head -n 20当前环境里我没复现到段错误反而看到是libpq library not found。我继续检查虚拟环境中已安装的gaussdb/gaussdb-c包和其.so依赖确认你之前 coredump 是不是来自另一个环境变量例如LD_LIBRARY_PATH指向了不兼容库。Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate python - ‘PY’import sys, site, pkgutilprint(‘python’, sys.executable)print(‘sys.path[0:5]’, sys.path[:5])mods [m.name for m in pkgutil.iter_modules() if m.name.startswith(‘gaussdb’)]print(‘gaussdb modules’, sorted(mods)[:20])PYRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate python -m pip show gaussdb gaussdb-c gaussdb-binary 2/dev/null || trueRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate python - ‘PY’import importlib.utilfor name in [‘gaussdb_c’,‘gaussdb_binary’,‘gaussdb’]:spec importlib.util.find_spec(name)print(name, ‘-’, spec.origin if spec else None)PYSearched for files matching**/gaussdb_c/**, no matchesRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate find .env311/lib/python3.11/site-packages -maxdepth 4 ( -name ‘gaussdb.so’ -o -name ‘_gaussdb*.so’ -o -name ‘libpq*.so*’ ) | sed ‘s#^#- #’我已经确认当前这个虚拟环境里没有任何gaussdb_c/gaussdb_binary二进制模块你之前的 core 更像是“曾经加载到了某个原生.so后崩溃”。我再看一眼连接路径的底层调用定义确认是否存在 ctypes 签名错误会导致连接失败时直接段错误。Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/_pq_ctypes.py#1-1), lines 1 to 260Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/pq_ctypes.py#1230-1230), lines 1230 to 1288Searched for regexPQinitOpenSSL|PQisthreadsafe|PQtrace|argtypes|restype(**/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/_pq_ctypes.py), 40 resultsSearched for textPQinitOpenSSL(**/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/_pq_ctypes.py), 4 resultsSearched for files matching**/test_gaussdb/gaussdb-python/**/gaussdb_c/**, no matchesRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate env | grep -E ‘^(PYTHONPATH|LD_LIBRARY_PATH|GAUSSDB|PG|PATH)’ | sortRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate python test1.py我这边运行 test1.py 现在是libpq not found和你刚才“能 import 但 segfault”的现场不同。为了把问题收敛我继续检查你 C 程序和 Python 进程各自实际链接到了哪个libpq/openssl这通常就是“C 不崩、驱动崩”的关键差异。Ran terminal command: cd /workspace/test_gaussdb ldd ./test_pq || trueRan terminal command: cd /workspace/test_gaussdb find gaussdb-libpq -maxdepth 3 -type f | sed ‘s#^#- #’ | head -n 80Ran terminal command: cd /workspace/test_gaussdb ls -l gaussdb-libpq/lib 2/dev/null || trueRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python -X faulthandler - ‘PY’import gaussdbimport gaussdb.pq as pqprint(‘import ok’, gaussdb.version, pq.impl, pq.version())try:conn gaussdb.connect(‘host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword’, connect_timeout3)print(‘connected’)except Exception as e:print(‘connect err:’, type(e).name, e)PY已经复现到同样的段错误了而且栈明确落在 pq_ctypes.py 的password - _call_bytes。我马上定位这段代码的指针生命周期判断是不是在连接失败清理阶段访问了已释放/无效PGconn。Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/pq_ctypes.py#150-150), lines 150 to 240Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/pq_ctypes.py#780-780), lines 780 to 860Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py#200-200), lines 200 to 280Read [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/generators.py#60-60), lines 60 to 130Searched for regexclass FinishedPGconn|FinishedPGconn\(|password:|db:|user:(**/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py), 7 resultsRead [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py#1-1), lines 1 to 110定位结果崩溃不是出在连接主流程而是失败清理逻辑finish_pgconn()里读取pgconn.password即调用PQpass时触发了 native segfault。接下来我会做一个最小修复在构造FinishedPGconn时跳过password字段避免触发这个不安全调用。Generating patch (14 lines) in [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py)Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python -X faulthandler - ‘PY’import gaussdbimport gaussdb.pq as pqprint(‘import ok’, gaussdb.version, pq.impl, pq.version())try:conn gaussdb.connect(‘host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword’, connect_timeout3)print(‘connected’)except Exception as e:print(‘connect err:’, type(e).name, e)PY发现这个libpq上不仅PQpass连PQhost在失败连接对象上也会触发段错误所以“跳过单个字段”不够。我要把finish_pgconn()改成不再读取任何连接属性只做PQfinish并返回默认快照这样可以彻底规避失败态PGconn的危险访问。Generating patch (16 lines) in [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py)Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python -X faulthandler - ‘PY’import gaussdbimport gaussdb.pq as pqprint(‘import ok’, gaussdb.version, pq.impl, pq.version())try:conn gaussdb.connect(‘host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword’, connect_timeout3)print(‘connected’)except Exception as e:print(‘connect err:’, type(e).name, e)PYRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python test1.pyChecked [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/errors.py), no problems foundCompleted:Inspect test scripts and imports(1/4)结论根因已定位不是连接本身崩而是在连接失败后的异常收尾阶段驱动会访问失败态 PGconn 的属性如 host/password底层会调用 PQhost/PQpass你这套 libpq 组合在该状态下返回了非法指针触发段错误。你的 C 示例不会崩是因为它只做 PQstatus/PQerrorMessage/PQfinish没有去读这些额外属性所以不会踩到这个崩溃点。我已做的修复已修改 errors.py 的 finish_pgconn()不再读取任何 PGconn 属性只执行 finish 并返回默认快照对象。复测结果同样失败连接场景下不再 coredump改为正常抛出 OperationalError。复现与验证复现崩溃修复前栈在 pq_ctypes.py 的 _call_bytes - host/password。修复后执行 test1.py配合你的 libpq输出为连接失败错误不再段错误。建议你本地运行方式先固定后端为 python并显式指定库路径GAUSSDB_IMPLpython LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH python test1.py要不要我再帮你加一个最小回归测试模拟连接失败时不崩溃这样后续升级驱动时可以自动防回归Made changes.User: “底层会调用 PQhost/PQpass”,libpq 组合在该状态下返回了非法指针这个能再细分析一下么GitHub Copilot: 这个可以再往下拆到“代码路径 C 层语义”两层。我先抓一份原生栈gdb backtrace确认是ctypes解引用坏指针还是libpq内部先崩再给你一个更可信的结论边界。Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate command -v gdb || true我现在跑一次最小复现脚本到 gdb目标是拿到崩溃点对应的 C 符号比如在PQhost内还是ctypes转换层。Ran terminal command: cd /workspace/test_gaussdb cat /tmp/repro_gauss_seg.py ‘PY’import gaussdbconn Nonetry:conn gaussdb.connect(‘host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword’, connect_timeout3)except Exception as e:print(type(e).name, e)finally:if conn:conn.close()PYLD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython gdb -q -batch -ex run -ex bt --args /workspace/test_gaussdb/.env311/bin/python /tmp/repro_gauss_seg.pyRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate timeout 25s env LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:L D L I B R A R Y P A T H G A U S S D B I M P L p y t h o n g d b − q − b a t c h − e x r u n − e x b t − − a r g s / w o r k s p a c e / t e s t g a u s s d b / . e n v 311 / b i n / p y t h o n / t m p / r e p r o g a u s s s e g . p y ; e c h o E X I T : LD_LIBRARY_PATH GAUSSDB_IMPLpython gdb -q -batch -ex run -ex bt --args /workspace/test_gaussdb/.env311/bin/python /tmp/repro_gauss_seg.py ; echo EXIT:LDL​IBRARYP​ATHGAUSSDBI​MPLpythongdb−q−batch−exrun−exbt−−args/workspace/testg​aussdb/.env311/bin/python/tmp/reprog​ausss​eg.py;echoEXIT:?Ran terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python -X faulthandler - ‘PY’from gaussdb import pqfrom gaussdb.pq._enums import ConnStatus, PollingStatusconn pq.PGconn.connect_start(b’host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword connect_timeout3’)for i in range(50):st conn.connect_poll()if st not in (PollingStatus.READING, PollingStatus.WRITING):breakprint(‘poll’, st, ‘status’, conn.status)Dangerous access on failed connection pathprint(‘about to read host bytes…’)print(conn.host)PYCompleted with input: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python -X faulthandler - ‘PY’from gaussdb import pqfrom gaussdb.pq._enums import ConnStatus, PollingStatusconn pq.PGconn.connect_start(b’host127.0.0.1 port3333 dbnamedatabase_name userusername passwordpassword connect_timeout3’)for i in range(50):st conn.connect_poll()if st not in (PollingStatus.READING, PollingStatus.WRITING):breakprint(‘poll’, st, ‘status’, conn.status)Dangerous access on failed connection pathprint(‘about to read host bytes…’)print(conn.host)PYRan terminal command: cd /workspace/test_gaussdb . .env311/bin/activate LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib:$LD_LIBRARY_PATH GAUSSDB_IMPLpython python - ‘PY’from gaussdb.pq import _pq_ctypes as implfrom gaussdb.pq.misc import version_prettyprint(‘loaded libname ’, impl.libname)print(‘PQlibVersion ’, impl.libpq_version, version_pretty(impl.libpq_version))PYRead [](file:///workspace/test_gaussdb/gaussdb-python/gaussdb/gaussdb/pq/misc.py#45-45), lines 45 to 110Ran terminal command: cd /workspace/test_gaussdb ldd gaussdb-libpq/lib/libpq.so.5.5Ran terminal command: cd /workspace/test_gaussdb LD_LIBRARY_PATH/workspace/test_gaussdb/gaussdb-libpq/lib ldd gaussdb-libpq/lib/libpq.so.5.5细化分析崩溃链路是连接失败后在 generators.py 调用finish_pgconn()随后在 errors.py 读取pgconn属性快照。这些属性如host、password会走到 pq_ctypes.py内部通过_call_bytes()调 C APIPQhost/PQpass见 pq_ctypes.py。_call_bytes()对c_char_p返回值会触发 ctypes 解引用如果 C 层返回的是“非空但无效地址”Python 来不及抛异常就会直接 SIGSEGV。你看到的 core 正是这一类崩溃。我做了独立最小复现在connect_poll失败后直接print(conn.host)无需上层框架也会立刻段错误所以问题不在异常对象构造本身而在“失败态 PGconn PQhost/PQpass 访问”这个组合。你 C 程序不崩是因为只调用了PQstatus/PQerrorMessage/PQfinish没有触发PQhost/PQpass路径。为什么说是 libpq 组合问题该驱动在 misc.py 用find_library(pq)动态找库实际加载结果受LD_LIBRARY_PATH、系统库优先级影响。你当前这套库报告PQlibVersion 90204 (9.2.4)但又来自 gaussdb-libpq 打包目录说明是“Gauss 发行库 当前系统运行时”的特定组合在这个组合里失败态访问某些字符串 getter 不安全。结论边界我能 100% 确认“崩溃触发点”是PQhost/PQpass在失败态PGconn上被调用。我不能在无 libpq 源码/符号的前提下 100% 断言是 libpq 内部 bug 还是 ABI 兼容性问题但工程上两者都应按“不安全调用路径”处理你现在的修复就是正确方向。如果你愿意我可以再给你一版更稳妥的补丁在pq_ctypes.PGconn.host/password/...上加“仅status OK才读”的防护这样即便别处再调用也不会 core。我测试了AI中间给的一个临时方案修改gaussdb的python驱动里的errors.py把deffinish_pgconn(pgconn:PGconn)-PGconn:args{}forfinfields(FinishedPGconn):try:args[f.name]getattr(pgconn,f.name)exceptException:passpgconn.finish()returnFinishedPGconn(**args)改成deffinish_pgconn(pgconn:PGconn)-PGconn:args{}pgconn.finish()returnFinishedPGconn(**args)即不读PGconn里的信息果然不会coredump了。基于AI的分析再思考但是我没有直接把这个方案给客户因为从AI分析的结果来看是libpq在连接失败的时候返回了无效地址被python的ctypes读取才导致的问题而这个python驱动此处的代码和开源的psycopg3里是完全一样的。这个时候客户突然反馈说之前他密码搞错了把密码改正确后airflow能正常启动了。。。我庆幸自己做复现测试的时候也是用了无效的连接地址才可以马上复现如果用了个有效连接我恐怕很难排查到这个问题了。但是华为的这个python驱动其实在github上是有工作流去自动测试的测试用例里也有连接失败的用例但这个工作流是跑通了的而且也跑了arm平台。对比了下差别在于它工作流用的ibpq是505.2版本的而我用的是506.0版本的。然后我马上配好505.2的libpq环境再来跑前面这几个测试程序都没core了到这里所有的现象综合起来问题直指ARM64环境中GaussDB在506.0版本中修改了libpq导致python驱动在连接失败时会coredump至于改了哪里由于没有源码只能让华为来解释了。我怀着侥幸心理用opengauss的libpq驱动测了下期望能coredump这样就有源码来分析结果并没有coredump。顺手给华为提了个issue,后续再看吧https://github.com/HuaweiCloudDeveloper/gaussdb-python/issues/30我感觉十有八九会先让python驱动这边修改因为如果libpq修改内核都得动。总结1. ARM64 云开发https://developer.huaweicloud.com/space/华为云的云开发环境里可以免费创建4台机器容器、虚拟机、开发桌面、云主机各一台容器最高配置为16C32G虚拟机最高2C4G,开发桌面和云主机最高为4C8G 后续云主机会和开发桌面合并其中容器和虚拟机均可在vscode里通过Huawei Developer Space插件直连体验和ssh远程开发完全一致copilot可以正常使用当然也可以直接使用华为云的CodeArts这款IDE工具。如果需要免费的ARM机器进行测试个人感觉华为云的这个云开发环境还算可以。只是这些环境都是虚拟化出来的如果想里面再虚拟化就有些麻烦了。2. AI AGENT现在应该还有很多人是在网页上用对话的方式来使用AI在网页和环境中反复复制粘贴效率极低。而有了agent后AI能直接操作环境它想查什么自己都能查不会出现AI不信你的情况了。像这次我用vscode copilot一句话下去让AI自己去定位问题都不用人看着反正这华为云上的开发机器随便操作权限全给也不担心把服务器弄坏大不了重新初始化服务器就行了。3. GaussDB libpq 版本用GaussDB的驱动涉及coredump的问题时以后除了考虑CPU平台、python版本还得再额外考虑下驱动本身的版本了这已经不是第一次发现506.0这个版本的libpq和505.2版本的表现行为不一致了。本文作者DarkAthena本文链接https://www.darkathena.top/archives/analyze-gaussdb-arm64-python-driver-psycopg3-coredump版权声明本博客所有文章除特别声明外均采用CC BY-NC-SA 3.0 许可协议。转载请注明出处