postgresql/src/interfaces/ecpg
Michael Paquier fa703b317e Fix error handling with threads on OOM in ECPG connection logic
An out-of-memory failure happening when allocating the structures to
store the connection parameter keywords and values would mess up with
the set of connections saved, as on failure the pthread mutex would
still be hold with the new connection object listed but free()'d.

Rather than just unlocking the mutex, which would leave the static list
of connections into an inconsistent state, move the allocation for the
structures of the connection parameters before beginning the test
manipulation.  This ensures that the list of connections and the
connection mutex remain consistent all the time in this code path.

This error is unlikely going to happen, but this could mess up badly
with ECPG clients in surprising ways, so backpatch all the way down.

Reported-by: ryancaicse
Discussion: https://postgr.es/m/17186-b4cfd8f0eb4d1dee@postgresql.org
Backpatch-through: 9.6
2021-09-13 13:23:50 +09:00
..
compatlib Make ecpg's rjulmdy() and rmdyjul() agree with their declarations. 2021-01-28 11:17:13 -05:00
ecpglib Fix error handling with threads on OOM in ECPG connection logic 2021-09-13 13:23:50 +09:00
include Fix some typos, grammar and style in docs and comments 2021-02-24 16:13:17 +09:00
pgtypeslib interval: round values when spilling to months 2021-08-03 12:10:29 -04:00
preproc Fix incorrect merge in ECPG code with DECLARE 2021-08-25 15:16:31 +09:00
test Improved ECPG warning as suggested by Michael Paquier and removed test case 2021-08-17 15:01:09 +02:00
Makefile Use https for gnu.org links 2020-10-14 08:24:54 +02:00
README.dynSQL Fix whitespace issues found by git diff --check, add gitattributes 2013-11-10 14:48:29 -05:00

src/interfaces/ecpg/README.dynSQL

descriptor statements have the following shortcomings

- input descriptors (USING DESCRIPTOR <name>) are not supported

  Reason: to fully support dynamic SQL the frontend/backend communication
          should change to recognize input parameters.
          Since this is not likely to happen in the near future and you
          can cover the same functionality with the existing infrastructure
          (using s[n]printf), I'll leave the work to someone else.