reduces the number of concurrent processes launched during parallel
regression tests, possibly avoiding failures such as exceeding a user's
max number of processes. This essentially completes the reversion
of 1.27->1.28.
vulnerability. This fix completely removes the ability (hack) of being able
to bind a list of values in an in clause. It was demonstrated that by allowing
that functionality you open up the possibility for certain types of
sql injection attacks. The previous fix attempts all focused on preventing
the insertion of additional sql statements (the semi-colon problem:
xxx; any new sql statement here). But that still left the ability to
change the where clause on the current statement or perform a subselect
which can circumvent applicaiton security logic and/or allow you to call
any stored function.
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
he supplied a few months ago, but didn't get around to docing until now. And
he also added some doc for calling stored functions in general from jdbc that was missing.
Modified Files:
sgml/jdbc.sgml
something wider than int on that platform. Also, remove bogus
assumption that sizeof("INT_MAX") has something to do with the maximum
number of digits in an int.
writing one more value into return arrays than will fit. This is
potentially a stack smash, though I do not think it is a problem in
current uses of the routine, since a failure return causes elog anyway.
in HAVE_INT64_TIMESTAMP cases, including two potential stack smashes
when more than six fractional digits were supplied. Per bug report
from Philipp Reisner.
and send() very well at all; and in any case we can't use retval==0
for EOF due to race conditions. Make the same fixes in the backend as
are required in libpq.
