are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few weeks/months. This keeps our options
open for making it do the right plpgsql-ish thing in future without
creating a backwards compatibility problem. There is no loss of
functionality since people can get the same behavior with CREATE TABLE AS.
Add -l option to name log file. Set umask to 077.
Proper file descriptor redirection to allow postmaster to detach from
shell's process group.
Add -s option to turn off informational messages.
any other client connections that may exist (which would only happen if
another client is currently in the authentication cycle). This avoids
wastage of open descriptors in a child. It might also explain peculiar
behaviors like not closing connections when expected, since the kernel
will probably not signal EOF as long as some other backend is randomly
holding open a reference to the connection, even if the client went away
long since ...
The driver version is 07.01.0002 now.
1) initialized pg_version by DSN's protocol info
so that we could always use pg_version info
once a connection is established (pg_version()
didn't exist before 6.4). PROTOCOL_XX() macros
are removed(except from connection.[ch]).
2) provided a few macros to encapsulate connection's
version info and replaced existent comparison
stuff by those macros.
3) change SQLTables() so that 7.1 servers could show
views.
In addtion, the following patch from Dave Page is applied.
This patch fixes a bug in SQLGetInfo for SQL_DBMS_VER which corrupted the
driver version string. The driver version number has also been incremented
to 07.01.0002.
Regards, Dave. <<odbc.diff>>
elog(ERROR) not an Assert trap, since we've downgraded out-of-memory to
elog(ERROR) not a fatal error. Also, change the hard boundary from 256Mb
to 1Gb, just so that anyone who's actually got that much memory to spare
can play with TOAST objects approaching a gigabyte.
- Some minor additions to Statement to make our own extensions more
portable.
- Statement.close() will now call ResultSet.close() rather than just
dissasociating with it.
- Fixed bug where Statement.setMaxRows() was a global setting. Now
limited to just itself.
- Changed LargeObject.read(byte[],int,int) to return the actual number
of bytes read (used to be void).
- LargeObject now supports InputStream's!
- PreparedStatement.setBinaryStream() now works!
- ResultSet.getBinaryStream() now returns an InputStream that doesn't
copy the blob into memory first!
- Connection.isClosed() now tests to see if the connection is still alive
rather than if it thinks it's alive.
allocated by plan nodes are not leaked at end of query. This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions. Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.
and two 'win32.mak'. Addresses the following:
1) Oops. Spelled fcntl.h wrong in the last one. D'uh.
2) PG_VERSION changed to be defined with " around it. psql/command.c failed
to compile without that.
3) Changed makefiles to use "/MD" and link both psql and libpq.dll against
MSVCRT.DLL instead of a static library. This takes care of the
crash-upon-free in psql.
I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander
ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've
been involved with...
Magnus Hagander
original table ('OLD' table) in its join tree if OLD is referenced by
either the rule action, the rule qual, or the original query qual that
will be added to the rule action. However, we only want one instance
of the original table to be included; so beware of the possibility that
the rule action already has a jointree entry for OLD.
regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I
submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines
like to compute nth place float point digits like Sun/Solaris does?
Otherwise, 7.1beta3 runs without problems (i.e. all other
regression tests pass) on my Sparc 20 running Debian GNU/Linux 2.2.
Ryan Kirkpatrick
rather than coredumping (as prior 7.1 code did) or silently dropping the
condition (as 7.0 did). This is annoying but there doesn't seem to be
any good way to fix it, short of a major querytree restructuring.
actually) to ensure that its file access time doesn't get old enough to
tempt a /tmp directory cleaner to remove it. Still another reason we
should never have put the sockets in /tmp in the first place ...
truncating to integer. Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.
dialogue from '6.4/6.5' to '6.5+' and removes some C++ comments from
resource.h (which VC++ insists on putting there).
odbc2.diff adds code to query the PostgreSQL version upon connection. This
is then used to determine what values to return for from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. The version string as returned by SELECT vERSION() (as
a char array) and the major.minor version number (as a flost) have been
added to the ConnectionClass structure.
Dave Page
and new root page if old root one was splitted but new root page
wasn't created.
New code is protected by FixBTree bool flag setted to FALSE, so
nothing should be affected by this untested approach.
some more osteric bugs is easier. If only 1 arg is supplied and it's
of type Exception, then that Exception's stacktrace is now included.
This was done as there's been a report of an unusual bug during connection.
This will make this sort of bug hunting easier from now on.
problems with char array sizes having set a couple of constants to 0 for
unlimited query length and row length. This additional patch cleans those
problems up by defining a new constant (STD_STATEMENT_LEN) to 65536 and
using that in place of MAX_STATEMENT_LEN.
Another constant (MAX_MESSAGE_LEN) was defined as 2*BLCKSZ, but is now
65536. This is used to define the length of the message buffer in a number
of places and as I understand it (probably not that well!) therefore also
places a limit on the query length. Fixing this properly is beyond my
capabilities but 65536 should hopefully be large enough for most people.
Apologies for being over-enthusiastic and posting 3 patches in one day
rather than 1 better tested one!
Regards,
Dave Page
> Sent: 24 January 2001 16:51
> To: Dave Page
> Subject: Re: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
>
>
> > SQL_OJ_LEFT = Left outer joins are supported.
>
> Yes.
<snip>
In addition to my earlier patch, this one adds support for SQLGetInfo
SQL_OJ_CAPABILITIES to the ODBC driver.
Dave Page
following but it does *not* check whether the user is connected to
PostgreSQL 7.0.x or 7.1 first (as would be required for some of the
features) - the driver doesn't do this at all afaik and it's beyond my
capabilities to implement such checking in code that doesn't look like it
was written by my 1 year old daughter!
1) The driver now reports no maximum query length (SQL_MAX_QUERY_SIZE).
2) The driver now reports no maximum row length (SQL_MAX_ROW_SIZE).
3) The driver now reports that Outer Joins are supported (SQL_OUTER_JOINS),
but still does not report oj capabilities (SQL_OJ_CAPABILITIES).
4) The version number has been incremented to 7.1.0000 in psqlodbc.h *and*
psqlodbc.rc
Regards,
Dave Page
objects that Thomas pointed out might be a problem.
PPS. I have included and updated the comments from the original patch
request to reflect the changes made in this revised patch.
> Attached is a set of patches for a couple of bugs dealing with
> timestamps in JDBC.
>
> Bug#1) Incorrect timestamp stored in DB if client timezone different
> than DB.
> The buggy implementation of setTimestamp() in PreparedStatement simply
> used the toString() method of the java.sql.Timestamp object to convert
> to a string to send to the database. The format of this is yyyy-MM-dd
> hh:mm:ss.SSS which doesn't include any timezone information. Therefore
> the DB assumes its timezone since none is specified. That is OK if the
> timezone of the client and server are the same, however if they are
> different the wrong timestamp is received by the server. For example if
> the client is running in timezone GMT and wants to send the timestamp
> for noon to a server running in PST (GMT-8 hours), then the server will
> receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
> 12:00:00-08 which is 2000-01-12 04:00:00 in GMT. The fix is to send a
> format to the server that includes the timezone offset. For simplicity
> sake the fix uses a SimpleDateFormat object with its timezone set to GMT
> so that '+00' can be used as the timezone for postgresql. This is done
> as SimpleDateFormat doesn't support formating timezones in the way
> postgresql expects.
>
> Bug#2) Incorrect handling of partial seconds in getting timestamps from
> the DB
>
> When the SimpleDateFormat object parses a string with a format like
> yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
> decimal places (time precision in java is miliseconds = three decimal
> places). This seems like a bug in java to me, but it is unlikely to be
> fixed anytime soon, so the postgresql code needed modification to
> support the java behaviour. So for example a string of '2000-01-12
> 12:00:00.12-08' coming from the database was being converted to a
> timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00. The
> fix was to check for a '.' in the string and if one is found append on
> an extra zero to the fractional seconds part.
>
>
> I also did some cleanup in ResultSet.getTimestamp(). This method has
> had multiple patches applied some of which resulted in code that was no
> longer needed. For example the ISO timestamp format that postgresql
> uses specifies the timezone as an offset like '-08'. Code was added at
> one point to convert the postgresql format to the java one which is
> GMT-08:00, however the old code was left around which did nothing. So
> there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
> yyyy-MM-dd hh:mm:sszzz. This second format would never be encountered
> because zzz (i.e. -08) would be converted into the former (also note
> that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
> number of z's does not matter).
>
>
> There was another problem/fix mentioned on the email lists today by
> mcannon@internet.com which is also fixed by this patch:
>
> Bug#3) Fractional seconds lost when getting timestamp from the DB
> A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
> but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
> The code is fixed to handle this case as well.
Barry Lind
to the use of getpwuid when running in standalone mode.
this patch allocates some persistent storage (using
strdup) to store the username obtained with getpwuid
in src/backend/main/main.c. this is necessary because
later on, getpwuid is called again (in ValidateBinary).
the man pages for getpwuid on SCO OpenServer, FreeBSD,
and Darwin all have words to this effect (this is from
the SCO OpenServer man page):
Note
====
All information is contained in a static area, so it must
be copied if it is to be saved. Otherwise, it may be
overwritten on subsequent calls to these routines.
in particular, on my platform, the storage used to hold
the pw_name from the first call is overwritten such that
it looks like an empty username. this causes a problem
later on in SetSessionUserIdFromUserName.
i'd assume this isn't a problem on most platforms because
getpwuid is called with the same UID both times, and the
same thing ends up happening to that static storage each
time. however, that's not guaranteed, and is _not_ what
happens on my platform (at least :).
this is for the version of 7.1 available via anon cvs as
of Tue Jan 23 15:14:00 2001 PST:
.../src/backend/main/main.c,v 1.37 2000/12/31 18:04:35 tgl Exp
-michael thornburgh, zenomt@armory.com
and psql) again. Changes are:
1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order
to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx)
2) PG_VERSION is no longer defined in version.h[.in], but in configure.in.
Since we don't do configure on native win32, we need to put it in
config.h.win32 :-(
3) Added define of SYSCONFDIR to config.h.win32 - libpq won't compile
without it. This functionality is *NOT* tested - it's just defined as "" for
now. May work, may not.
4) DEF_PGPORT renamed to DEF_PGPORT_STR
I have done the "basic tests" on it - it connects to a database, and I can
run queries. Haven't tested any of the fancier functions (yet).
However, I stepped on a much bigger problem when fixing psql to work. It no
longer works when linked against the .DLL version of libpq (which the
Makefile does for it). I have left it linked against this version anyway,
pending the comments I get on this mail :-)
The problem is that there are strings being allocated from libpq.dll using
PQExpBuffers (for example, initPQExpBuffer() on line 92 of input.c). These
are being allocated using the malloc function used by libpq.dll. This
function *may* be different from the malloc function used by psql.exe - only
the resulting pointer must be valid. And with the default linking methods,
it *WILL* be different. Later, psql.exe tries to free() this string, at
which point it crashes because the free() function can't find the allocated
block (it's on the allocated blocks list used by the runtime lib of
libpq.dll).
Shouldn't the right thing to do be to have psql call termPQExpBuffer() on
the data instead? As it is now, gets_fromFile() will just return the pointer
received from the PQExpBuffer.data (this may well be present at several
places - this is the one I was bitten by so far). Isn't that kind of
"accessing the internals of the PQExpBuffer structure" wrong? Instead,
perhaps it shuold make a copy of the string, adn then termPQExpBuffer() it?
In that case, the string will have been allocated from within the same
library as the free() is called.
I can get it to work just fine by doing this - changing from (around line
100 of input.c):
and the same a bit further down in the same function.
But, as I said above, this may be at more places in the code? Perhaps
someone more familiar to it could comment on that?
What do you think shuld be done about this? Personally, I go by the "If you
allocate a piece of memory using an interface, use the same interface to
free it", but the question is how to make it work :-)
Also, AFAIK this only affects psql.exe, so the changes made to the libpq
this patch are required no matter how the other issue is handled.
Regards,
Magnus
than forcing 'plain'. This probably does not matter right now, but I
think it needs to be consistent with the regular (not-functional) index
case, where attstorage is copied from the underlying table. Clean up
some other dead and infelicitous code too.
Op, so that the sequence 'a_expr Op Op a_expr' will be parsed as
a_expr Op (Op a_expr) not (a_expr Op) Op a_expr as formerly. In other
words, prefer treating user-defined operators as prefix operators to
treating them as postfix operators, when there is an ambiguity.
Also clean up a couple of other infelicities in production priority
assignment --- for example, BETWEEN wasn't being given the intended
priority, but that of AND.
Query used for checking foreign key triggers
returns too many results when there're more than one foreign
key in a table. It happens because only table's oid is used to
link between pg_trigger with INSERT check and pg_trigger with
UPDATE/DELETE check.
I think there should be enough to add following conditions
into WHERE clause of that query:
AND pt.tgconstrname = pg_trigger.tgconstrname
AND pt.tgconstrname = pg_trigger_1.tgconstrname
/Constantin
bothering to check the return value --- which meant that in case the
update or delete failed because of a concurrent update, you'd not find
out about it, except by observing later that the transaction produced
the wrong outcome. There are now subroutines simple_heap_update and
simple_heap_delete that should be used anyplace that you're not prepared
to do the full nine yards of coping with concurrent updates. In
practice, that seems to mean absolutely everywhere but the executor,
because *noplace* else was checking.
attributes in a FieldSelect node --- all the places that manipulate
these work just fine with system attribute numbers. OK, it's a new
feature, so shoot me ...
eliminates a raft of portability issues, including whether sys_nerr
exists, whether the platform has any valid negative errnos, etc. The
downside is minimal: errno shouldn't ever contain an invalid value anyway,
and if it does, reasonably modern versions of strerror will not choke.
This rangecheck idea seemed good at the time, but it's clearly a net loss,
and I apologize to all concerned for having ever put it in.
rewrite of deadlock checking. Lock holder objects are now reachable from
the associated LOCK as well as from the owning PROC. This makes it
practical to find all the processes holding a lock, as well as all those
waiting on the lock. Also, clean up some of the grottier aspects of the
SHMQueue API, and cause the waitProcs list to be stored in the intuitive
direction instead of the nonintuitive one. (Bet you didn't know that
the code followed the 'prev' link to get to the next waiting process,
instead of the 'next' link. It doesn't do that anymore.)
here is the patch attached which do check in each BLOB operation, if we are
in transaction, and raise an error otherwise. This will prevent such mistakes.
--
Sincerely Yours,
Denis Perchine
of c.h altogether, and putting it into the only places that use it
(elog.c and exc.c), instead. Modify these routines to check for a
NULL or empty-string return from strerror, too, since some platforms
define strerror to return empty string for unknown errors (what a useless
definition that is ...). Clean up some cruft in ExcPrint while at it.
whitespace is unimportant in assembly code. Also, move VAX definition
of typedef slock_t to port header files to be like all the other ports.
Note that netbsd.h and openbsd.h are now identical, and I rather think
that freebsd.h is broken in the places where it doesn't agree --- but
I'll leave it to the freebsders to look at that.
* doc/FAQ_MSWIN: Update to be consistent with software -- mainly change
comment from lack of Cygwin UNIX domain socket support and to list of
current Cygwin UNIX domain socket issues.
* src/include/config.h.in: Enable UNIX domain sockets for Cygwin.
* src/include/port/win.h: Disable UNIX domain sockets for Cygwin b20.1.
* src/test/regress/pg_regress.sh: Use UNIX domain sockets for Cygwin
instead of TCP/IP.
#! /usr/local/bin/perl -w
to
#! /usr/bin/perl
The path is probably more portable, and the -w was kind of silly for a six
line script that produces two warnings as it stands.
> > enable the :bash_math opcodes. Currently plperl.c only
> > enables the :default opcodes. This leave out about five of six
> > math functions including sqrt().
Travis Bauer
- Applied patch submitted by John Schutz <schutz@austin.rr.com> that
fixed a bug with ANT's SQL functions (not needed for building but nice
to have fixed).
- Added new error message into errors.properties "postgresql.notsensitive"
This is used by jdbc2.ResultSet when a method is called that should
fetch the current value of a row from the database refreshRow() for
example.
- These methods no longer throw the not implemented but the new noupdate
error. This is in preparation for the Updateable ResultSet support
which will overide these methods by extending the existing class to
implement that functionality, but needed to show something other than
notimplemented:
moveToCurrentRow()
moveToInsertRow()
rowDeleted()
rowInserted()
all update*() methods, except those that took the column as a String
as they were already implemented to convert the String to an int.
- getFetchDirection() and setFetchDirection() now throws
"postgresql.notimp" as we only support one direction.
The CursorResultSet will overide this when its implemented.
- Created a new class under jdbc2 UpdateableResultSet which extends
ResultSet and overides the relevent update methods.
This allows us to implement them easily at a later date.
- In jdbc2.Connection, the following methods are now implemented:
createStatement(type,concurrency);
getTypeMap();
setTypeMap(Map);
- The JDBC2 type mapping scheme almost complete, just needs SQLInput &
SQLOutput to be implemented.
- Removed some Statement methods that somehow appeared in Connection.
- In jdbc2.Statement()
getResultSetConcurrency()
getResultSetType()
setResultSetConcurrency()
setResultSetType()
- Finally removed the old 6.5.x driver.
- These methods in org.postgresql.jdbc2.ResultSet are now implemented:
getBigDecimal(int) ie: without a scale (why did this get missed?)
getBlob(int)
getCharacterStream(int)
getConcurrency()
getDate(int,Calendar)
getFetchDirection()
getFetchSize()
getTime(int,Calendar)
getTimestamp(int,Calendar)
getType()
NB: Where int represents the column name, the associated version
taking a String were already implemented by calling the int
version.
- These methods no longer throw the not implemented but the new noupdate
error. This is in preparation for the Updateable ResultSet support
which will overide these methods by extending the existing class to
implement that functionality, but needed to show something other than
notimplemented:
cancelRowUpdates()
deleteRow()
- Added new error message into errors.properties "postgresql.noupdate"
This is used by jdbc2.ResultSet when an update method is called and
the ResultSet is not updateable. A new method notUpdateable() has been
added to that class to throw this exception, keeping the binary size
down.
- Added new error message into errors.properties "postgresql.psqlnotimp"
This is used instead of unimplemented when it's a feature in the
backend that is preventing this method from being implemented.
- Removed getKeysetSize() as its not part of the ResultSet API
Thu Jan 18 09:46:00 GMT 2001 peter@retep.org.uk
- Applied modified patch from Richard Bullington-McGuire
<rbulling@microstate.com>. I had to modify it as some of the code
patched now exists in different classes, and some of it actually
patched obsolete code.
Wed Jan 17 10:19:00 GMT 2001 peter@retep.org.uk
- Updated Implementation to include both ANT & JBuilder
- Updated README to reflect the changes since 7.0
- Created jdbc.jpr file which allows JBuilder to be used to edit the
source. JBuilder _CAN_NOT_ be used to compile. You must use ANT for
that. It's only to allow JBuilders syntax checking to improve the
drivers source. Refer to Implementation for more details
mixed-signs. Previous effort left way too many minus signs, and was at
least as broken as the one before that :(
Clean up "ISO-style" time interval representation to omit zero fields if
there is at least one non-zero field. Supress some leading plus signs
when not necessary for clarity.
Replace every #ifdef __CYGWIN__ block with a cleaner TIMEZONE_GLOBAL macro
defined in datetime.h.
try to push restrictions on the view down into the view subquery,
so that they can become indexscan quals or what-have-you rather than
being applied at the top level of the subquery. 7.0 and before were
able to do this, though in a much klugier way, and I'd hate to have
anyone complaining that 7.1 is stupider than 7.0 ...
using POSIX semaphores more robust on Darwin 1.2/Mac OS X
Public Beta. this is for the version of 7.1 available
via anon cvs as of Jan 14 2001 14:00 PST.
since the semaphores and shared memory created by this
emulator are shared with the backends via fork(), their
persistent names are not necessary. removing their
names with shm_unlink() and sem_unlink() after creation
obviates the need for any "ipcclean" function. further,
without these changes, the shared memory (and, therefore,
the semaphores) will not be re-initialized/re-created after
the first execution of the postmaster, until reboot
or until some (non-existent) ipcclean function is executed.
this patch does the following:
1) if the shared memory segment "SysV_Sem_Info" already
existed, it is cleaned up. it shouldn't be there anyways.
2) the real indicator for whether the shared memory/semaphore
emulator has been initialized is if "SemInfo" has been
initialized. the shared memory and semaphores must be
initialized regardless of whether there was a garbage shared
memory segment lying around.
3) the shared memory segment "SysV_Sem_Info" is created with "O_EXCL"
to catch the case where two postmasters might be starting
simultaneously, so they don't both end up with the same shared
memory (one will fail). note that this can't be done with the
semaphores because Darwin 1.2 has a bug where attempting to
open an existing semaphore with "O_EXCL" set will ruin the
semaphore until the next reboot.
4) the shared memory segment "SysV_Sem_Info" is unlinked after
it is created. it will then exist without a name until the
postmaster and all backend children exit.
5) all semaphores are unlinked after they are created. they'll
then exist without names until the postmaster and all backend
children exit.
-michael thornburgh, zenomt@armory.com
Not sure why some were this way, and others were already correct, but it
seems to have been like this for several years.
This caused problems on a few damaged platforms like AIX and IRIX which do
not support DST calculations for years before 1970.
Thanks to Andreas Zeugswetter <ZeugswetterA@wien.spardat.at> for finding
the problem.
I hope. I finally realized that we were going at it backwards: when
there are excess parentheses, they need to be treated as part of the
sub-SELECT, not as part of the surrounding expression. Although either
choice yields an unambiguous grammar, only this way produces a grammar
that is LALR(1). With the old approach we were guaranteed to fail on
either 'SELECT (((SELECT 2)) + 3)' or
'SELECT (((SELECT 2)) UNION SELECT 2)' depending on which way we
resolve the initial shift/reduce conflict. With the new way, the same
reduction track can be followed in both cases until we have advanced
far enough to know whether we are done with the sub-SELECT or not.
given the fundamental restriction of not looking at transaction commit
data in pg_log. Use code that is actually based on tqual.c rather than
ad-hoc tests. Also write the tuple fetch loop using standard access
macros rather than ad-hoc code.
GetRawDatabaseInfo() won't cope with a compressed path spec (much less
a moved-off one). I'm not going to force an initdb for this change,
because it's noncritical --- we're not actually using datpath at all
right now. But it seems a good idea to apply the fix while I'm thinking
about it.
are treated more like 'cancel' interrupts: the signal handler sets a
flag that is examined at well-defined spots, rather than trying to cope
with an interrupt that might happen anywhere. See pghackers discussion
of 1/12/01.
---------------------------------------------------------------------------
Attached is a set of patches for a couple of bugs dealing with
timestamps in JDBC.
Bug#1) Incorrect timestamp stored in DB if client timezone different
than DB.
timestamps in JDBC.
Bug#1) Incorrect timestamp stored in DB if client timezone different
than DB.
The buggy implementation of setTimestamp() in PreparedStatement simply
used the toString() method of the java.sql.Timestamp object to convert
to a string to send to the database. The format of this is yyyy-MM-dd
hh:mm:ss.SSS which doesn't include any timezone information. Therefore
the DB assumes its timezone since none is specified. That is OK if the
timezone of the client and server are the same, however if they are
different the wrong timestamp is received by the server. For example if
the client is running in timezone GMT and wants to send the timestamp
for noon to a server running in PST (GMT-8 hours), then the server will
receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
12:00:00-08 which is 2000-01-12 04:00:00 in GMT. The fix is to send a
format to the server that includes the timezone offset. For simplicity
sake the fix uses a SimpleDateFormat object with its timezone set to GMT
so that '+00' can be used as the timezone for postgresql. This is done
as SimpleDateFormat doesn't support formating timezones in the way
postgresql expects.
Bug#2) Incorrect handling of partial seconds in getting timestamps from
the DB
When the SimpleDateFormat object parses a string with a format like
yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
decimal places (time precision in java is miliseconds = three decimal
places). This seems like a bug in java to me, but it is unlikely to be
fixed anytime soon, so the postgresql code needed modification to
support the java behaviour. So for example a string of '2000-01-12
12:00:00.12-08' coming from the database was being converted to a
timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00. The
fix was to check for a '.' in the string and if one is found append on
an extra zero to the fractional seconds part.
Bug#3) Performance problems
In fixing the above two bugs, I noticed some things that could be
improved. In PreparedStatement.setTimestamp(),
PreparedStatement.setDate(), ResultSet.getTimestamp(), and
ResultSet.getDate() these methods were creating a new SimpleDateFormat
object everytime they were called. To avoid this unnecessary object
creation overhead, I changed the code to use static variables for
keeping a single instance of the needed formating objects.
Also the code used the + operator for string concatenation. As everyone
should know this is very inefficient and the use of StringBuffers is
prefered.
I also did some cleanup in ResultSet.getTimestamp(). This method has
had multiple patches applied some of which resulted in code that was no
longer needed. For example the ISO timestamp format that postgresql
uses specifies the timezone as an offset like '-08'. Code was added at
one point to convert the postgresql format to the java one which is
GMT-08:00, however the old code was left around which did nothing. So
there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
yyyy-MM-dd hh:mm:sszzz. This second format would never be encountered
because zzz (i.e. -08) would be converted into the former (also note
that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
number of z's does not matter).
There was another problem/fix mentioned on the email lists today by
mcannon@internet.com which is also fixed by this patch:
Bug#4) Fractional seconds lost when getting timestamp from the DB
A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
The code is fixed to handle this case as well.
Barry Lind
are now critical sections, so as to ensure die() won't interrupt us while
we are munging shared-memory data structures. Avoid insecure intermediate
states in some code that proc_exit will call, like palloc/pfree. Rename
START/END_CRIT_CODE to START/END_CRIT_SECTION, since that seems to be
what people tend to call them anyway, and make them be called with () like
a function call, in hopes of not confusing pg_indent.
I doubt that this is sufficient to make SIGTERM safe anywhere; there's
just too much code that could get invoked during proc_exit().
- Fix handling of --tables=* (multiple tables never worked properly, AFAICT)
- strdup() the current user in DB routines
- Check results of IO routines more carefully.
- Check results of PQ routines more carefully.
Have not fixed index output yet.
1. Support of variable size keys - new algorithm of insertion to tree
(GLI - gist layrered insertion). Previous algorithm was implemented
as described in paper by Joseph M. Hellerstein et.al
"Generalized Search Trees for Database Systems". This (old)
algorithm was not suitable for variable size keys and could be
not effective ( walking up-down ) in case of multiple levels split
Bug fixed:
1. fixed bug in gistPageAddItem - key values were written to disk
uncompressed. This caused failure if decompression function
does real job.
2. NULLs handling - we keep NULLs in tree. Right way is to remove them,
but we don't know how to inform vacuum about index statistics. This is
just cosmetic warning message (like in case with R-Tree),
but I'm not sure how to recognize real problem if we remove NULLs
and suppress this warning as Tom suggested.
3. various memory leaks
This work was done by Teodor Sigaev (teodor@stack.net) and
Oleg Bartunov (oleg@sai.msu.su).
entry:
----------------------------
revision 1.2
date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines:
+18 -18
Eliminate some of the more blatant platform-dependencies ... it
builds here now, anyway ...
----------------------------
Which basically changes u_int*_t -> uint*_t, so now it does not
compile neither under Debian 2.2 nor under NetBSD 1.5 which
is platform independent<B8> all right. Also it replaces $KAME$
with $Id$ which is Bad Thing. PostgreSQL Id should be added as a
separate line so the file history could be seen.
So here is patch:
* changes uint*_t -> uint*. I guess that was the original
intention
* adds uint64 type to include/c.h because its needed
[somebody should check if I did it right]
* adds back KAME Id, because KAME is the master repository
* removes stupid c++ comments in pgcrypto.c
* removes <sys/types.h> from the code, its not needed
--
marko
Marko Kreen
- no more elog(STOP) in StartupXLOG();
- both checkpoint' undo & redo are used to define
oldest on-line log file.
2. Ability to pre-allocate a few log files at checkpoint time
(wal_files option). Off by default.
as both a GROUP BY item and an output expression, the top-level Group
node should just copy up the evaluated expression value from its input,
rather than re-evaluating the expression. Aside from any performance
benefit this might offer, this avoids a crash when there is a sub-SELECT
in said expression.
before calling RelationInvalidateHeapTuple(), which is bad because the
latter needs to look at the tuple data, which is in the shared disk
buffer. If another backend manages to recycle the buffer while this
is going on, we will compute the wrong hashindex for the tuple or
maybe even crash outright. Must hold buffer refcount until afterwards.
(This bug is not in 7.0.*; seems to be have introduced during WAL changes.)
and burn. Just for added luck, change reading of CONST nodes so that
we do not need to consult pg_type rows while reading them; this means
that no database access occurs during stringToNode. This requires
changing the order in which const-node fields are written, which means
an initdb is forced.
in per-entry sub-memory-context, where they were supposed to go, rather
than in CacheMemoryContext where the code was putting them. Must've
suffered a severe brain fade when I wrote this :-(
sequences. This is done by disabling multi-byte awareness when it's
not necessary. This is kind of a workaround, not a perfect solution.
However, there is no ideal way to parse broken multi-byte character
sequences. So I guess this is the best way what we could do right
now...
and revert documentation to describe the existing INHERITS clause
instead, per recent discussion in pghackers. Also fix implementation
of SQL_inheritance SET variable: it is not cool to look at this var
during the initial parsing phase, only during parse_analyze(). See
recent bug report concerning misinterpretation of date constants just
after a SET TIMEZONE command. gram.y really has to be an invariant
transformation of the query string to a raw parsetree; anything that
can vary with time must be done during parse analysis.
Previous result did not have correct month boundaries so anything near edge
cases was suspect (e.g. April was in Q1 and July, August were lumped into
Q2).
Thanks to Denis Osadchy <osadchy@turbo.nsk.su> for the report.
The leak is caused by the memory allocation in
src/interfaces/ecpg/lib/execute.c in line 669 which is never freed.
Adding a "free(array_query);" after PQexec in line 671 seems to fix the
leak.
Thorsten Knabe
starting a new hashtable search no longer clobbers any other search
active anywhere in the system. Fix RelationCacheInvalidate() so that
it will not crash or go into an infinite loop if invoked recursively,
as for example by a second SI Reset message arriving while we are still
processing a prior one.
