of transaction isolation level changed from uppercase to lower case between 7.3 and 7.4. In testing, a regression was also fixed in this area when talking to
a 7.2 server due to changes in how notice messages are processed in the current
code.
Modified Files:
jdbc/build.xml jdbc/org/postgresql/core/BaseStatement.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
yet, though). Avoid using nth() to fetch tlist entries; provide a
common routine get_tle_by_resno() to search a tlist for a particular
resno. This replaces a couple uses of nth() and a dozen hand-coded
search loops. Also, replace a few uses of nth(length-1, list) with
llast().
index pages: when _bt_getbuf asks the FSM for a free index page, it is
possible (and, in some cases, even moderately likely) that the answer
will be the same page that _bt_split is trying to split. _bt_getbuf
already knew that the returned page might not be free, but it wasn't
prepared for the possibility that even trying to lock the page could
be problematic. Fix by doing a conditional rather than unconditional
grab of the page lock.
gcc -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/include -c -o pg_id.o pg_id.c -MMD
pg_id.c: In function `main':
pg_id.c:35: warning: unused variable `optarg'
The attached trivial patch fixes the warning by removing the variable.
Neil Conway
encountered; per bug report from Christian van der Leeden 8/7/03.
Also, adjust larger/smaller routines (MAX/MIN) to share code with
comparisons for timestamp, interval, timetz.
getopt_long(). This is more or less the same problem as we saw earlier
with getaddrinfo() and struct addrinfo, and for the same reason: random
user-added libraries might contain the subroutine, but there's no
guarantee we will find the matching header files.
subplan it starts with, as they may be needed at upper join levels.
See comments added to code for the non-obvious reason why. Per bug report
from Robert Creager.
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
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.
completely useless error message in 'allow' case, don't retry connection
at the sendauth stage (by then the server will either let us in or not,
no point in wasting cycles on another try in the other SSL state).
that OS=hpux is the same as CPU=hppa. First steps at doing this.
With these patches, we still work on hppa with either gcc or HP's cc.
We might work on hpux/itanium with gcc, but I can't test it. Definitely
will not work on hpux/itanium with non-gcc compiler, for lack of spinlock
code.
might have inherited from the environment that would possibly cause
psql to fail to connect to the temp installation properly. Per trouble
report from Markus Bertheau 7/1/03.
Barry Lind
Tom Lane
Peter Eisentraut
Bruce Momjian
Michael Meskes
Marc G. Fournier