diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-06-14 18:16:46 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-06-14 18:16:46 -0400 |
| commit | 12b8fb34a933456ca762c98bc2047e608b7a1079 (patch) | |
| tree | 581aeb124d1dcae03497aef06e5fb898dac98bb2 /src/backend/access/gist/gistbuildbuffers.c | |
| parent | d6d9ea0a468bd5a8bf0feb98e41f1ecb4b8a173d (diff) | |
| download | postgresql-12b8fb34a933456ca762c98bc2047e608b7a1079.tar.gz postgresql-12b8fb34a933456ca762c98bc2047e608b7a1079.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/gistbuildbuffers.c')
0 files changed, 0 insertions, 0 deletions