If the remote server cannot be connected and query is canceled, don't show random warning about "Unfinished connection". Patch by Fazal Majid
Without it, the test can fail occasionally. Reported by Peter Eisentraut.
Otherwise it can still hang.
the validator is too big change for 2.5.1
Previous check was too broad and left plproxy hanging. Reported-By: Tarvi Pillessaar
Refactor some internals to make this possible. Mainly, FunctionCallInfo is not available when validating, so avoid accessing that if not required. Rename plproxy_compile() to plproxy_compile_and_cache() and the previously internal fn_compile() to plproxy_compile(). This matches their purpose better and allows the validator to call plproxy_compile() without invoking execution-time dependent code. Many error test cases have changed because the validator catches errors when the function is created, not when it is called. Raise the extension version to 2.5.1 to be able to upgrade from non-validator installations.
* use installed pg_buildext * use installed pgxs_debian_control.mk * don't override 'clean' target in debian/rules * 'make deb' forces control file regeneration This reduces crap maintained locally. It also does mean that to build against server-dev-X.Y package that is not for Debians default Postgres version, following packages need to be installed from PGDG (wiki.postgresql.org/wiki/Apt) repo: postgresql-client-common postgresql-common postgresql-server-dev-all
Fix build with PostgreSQL 9.3devel
Some needed declarations have been moved to the new header htup_details.h. stringinfo.h needs to be included explicitly now. It should always have been necessary, but might have come in through other headers.
Also throw error on unknown proargmode. Fixes crash reported by Sébastien Lardière.
Previously, as soon as cancel requests were send, plproxy re-throwed the error, without waiting for reaction from backend. Such behaviour creates 2 problems: - If plproxy backend is closed immediately, the bouncer will see plproxy close before cancel from backend, thus seeing mid-tx close, thus dropping the connection. - If new query comes in to plproxy backend, plproxy itself will see dirty connection, closing it, thus also causing close of server connection in bouncer. In both cases it can cause server connection drop in pooler. New behaviour of waiting query result should fix it.
On each call, recheck type relation rowstamp. If it proves to be noticeable, we can use syscache callback infrastructure for that, but it will be much more complex.
Otherwise there can be garbage in struct