aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-06-14 18:16:46 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-06-14 18:16:46 -0400
commitba412c905af14699a128a7bcd8ce5234adb93ceb (patch)
tree6f86ac7383076693441426ead925605cd98df184 /src/backend/access/gist/gistvalidate.c
parentd26ac35d0d7cb42a0453e69e0e9ce6d163b55927 (diff)
downloadpostgresql-ba412c905af14699a128a7bcd8ce5234adb93ceb.tar.gz
postgresql-ba412c905af14699a128a7bcd8ce5234adb93ceb.zip
Avoid ecpglib core dump with out-of-order operations.
If an application executed operations like EXEC SQL PREPARE without having first established a database connection, it could get a core dump instead of the expected clean failure. This occurred because we did "pthread_getspecific(actual_connection_key)" without ever having initialized the TSD key actual_connection_key. The results of that are probably platform-specific, but at least on Linux it often leads to a crash. To fix, add calls to ecpg_pthreads_init() in the code paths that might use actual_connection_key uninitialized. It's harmless (and hopefully inexpensive) to do that more than once. Per bug #17514 from Okano Naoki. The problem's ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17514-edd4fad547c5692c@postgresql.org
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions