…+ changes the API in the events subsystem.
…g logging was enabled in the nginx build. thanks buddy-ekb for the report in #21.
…anges the ngx_sock_ntop API. thanks an0ma1ia for the report in #19.
…m_finalize_request to suppress clang warnings.
…n the nginx error log file when the pg connection pool was used and the worker process was shutting down. this issue could be captured by running t/sanity.t with the environment TEST_NGINX_USE_HUP=1.
…east) libpq fails to connect to the remote database.
The "re-polling" hack to work-around the case in which both: read and write events occured within the same event processing call was being used for any CONNECTION_MADE status, without checking if the write really occured. Based on patch from Yichun Zhang (agentzh). Change-Id: Ia8310a109baf639d1c5c3c766d2298c3610e6d47 Signed-off-by: Piotr Sikora <firstname.lastname@example.org>
Reported by Yichun Zhang (agentzh). Change-Id: I9411e72ccfdbb0d974a92b6cba569dc15254ed3d Signed-off-by: Piotr Sikora <email@example.com>
The issue that hit many (most?) of PostgreSQL adapters is that libpq-8.x is unable to unescape bytea data from results in text format received from PostgreSQL-9.x. But we're always passing bytea data as is to the client (either from results in binary format when using "postgres_output binary_value" or escaped from results in text format), so this isn't problem for us. Patch from Yichun Zhang (agentzh).
Starting with PostgreSQL 9.0, libpq's PQcmdTuples() returns row count for SELECT queries (previously it returned empty string). Because we're using this value to detect number of changed rows, both: "postgres_rewrite" directive and "$postgres_affected" variable were working incorrectly. Reported by Yichun Zhang (agentzh).
…not found at all and returns 500 in this case instead of returning empty response.