- 18 Jan, 2001 5 commits
-
-
Thomas G. Lockhart authored
-
Bruce Momjian authored
-
Hiroshi Inoue authored
the tuple is already uodated. (If LockClassinfoForUpdate() is thought to be useful).
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 17 Jan, 2001 6 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
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
-
Bruce Momjian authored
-
Thomas G. Lockhart authored
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.
-
Bruce Momjian authored
Chapter 10. PL/pgSQL - SQL Procedural Language (c40914117.htm) Statements ... (resulting in a PL/pgSQL internal SELECT). But there are cases where someone isn't interested int -----------------------------------------(have to be)--> But there are cases where someone isn't interested in the functions result. RAISE level format'' --(have to be)--> RAISE level 'format'
-
Bruce Momjian authored
this file to match all the other files, and to be clearer.
-
- 16 Jan, 2001 3 commits
- 15 Jan, 2001 4 commits
-
-
Tom Lane authored
-
Peter Eisentraut authored
-
Tom Lane authored
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.
-
Tom Lane authored
on the old tuple's page while we are doing TOAST pushups.
-
- 14 Jan, 2001 6 commits
-
-
Tom Lane authored
-
Tom Lane authored
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.
-
Tom Lane authored
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.
-
Tom Lane authored
Otherwise, newly connecting backends will still think the deleted DB is valid, and will generate unexpected error messages.
-
Tom Lane authored
it now returns true if the aclitem argument exactly matches any one of the elements of the aclitem[] argument. Per complaint from Wolff 1/10/01.
-
Tom Lane authored
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.
-
- 13 Jan, 2001 16 commits
-
-
Peter Eisentraut authored
etc.
-
Bruce Momjian authored
--------------------------------------------------------------------------- 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.
-
Peter Eisentraut authored
SQL type names over internal type names.
-
Bruce Momjian authored
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
-
Bruce Momjian authored
-
Tom Lane authored
rule. Needed to avoid failure when reloading a 7.0 pg_dump of a view that has a NUMERIC column.
-
Peter Eisentraut authored
-
Marc G. Fournier authored
check one last time for any erros ...
-
Peter Eisentraut authored
shows up in psql now.
-
Marc G. Fournier authored
ignore his too
-
Marc G. Fournier authored
and this time?
-
Marc G. Fournier authored
try this again ...
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Bruce Momjian authored
-
Marc G. Fournier authored
okay, this appears to work ... onlly changes aer adding some white space ...
-