…Misbakh-Soloviov for the original patch in #38.
…+ 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>
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.
… we should have defined rds_rough_col_type_t as a type rather than a global variable. thanks @姜大炮.
This is second part of the "write proper SQL queries" campaign. Queries that return more than one value will result in "500 Internal Server Error" response.
This is more general approach, which forces writing proper SQL queries instead of filtering results on the nginx side and allows for sending output from multiple rows to end-users. Discussed with Silly Sad.
Because ngx_http_upstream_finalize_request sends NGX_HTTP_LAST, having last_buf=1 in our module meant that last two chains always had last_buf=1, which resulted in duplicated last chunk sent for HTTP/1.1 requests. This pretty much killed keep-alived requests. Reported by Silly Sad, diagnosed by Maxim Dounin. Same issue was independently diagnosed and fixed in ngx_drizzle by Yichun Zhang (agentzh) few days ago.
…art from most of the ngx_log_error calls in ngx_postgres_keepalive.c because they are duplicate with the << upstream: "postgres://ip.add.re.ss:port" >> part automatically generated by the ngx_http_log_error_handler function in the nginx core.
…d "sockaddr" fields instead of passing pointers around.
…, "sockaddr", and "socklen" fields for the connection from the pool such that we can get more detailed error log messages with the "upstream: postgres://ip.add.re.ss:port" bit.
I've just tested each case and there is no such bug in ngx_postgres, each error.log entry contains correct upstream peer name. I'll re-add "pc->name = &peer->name;" in case nginx or 3rd-party modules will ever use it, but "pc->name" isn't used by ngx_postgres. This reverts commit 8126a4f.
r->upstream->peer.name in the get_peer function which caused error messages lacking upstream peer names and ports.