Re: [HACKERS] New packages built ...
On 8.1.1 compiled and installed on Mac OS X 10.4.3 using only the
provided libraries, I'm receiving the following error when exiting psql:
could not save history to file "/{homedir}/.psql_history":
Invalid argument
I see that Tom Lane tracked down the problem back on August 28th:
http://archives.postgresql.org/pgsql-hackers/2005-08/msg01013.php
Because the error still exists, I'm assuming that no fix was put
into place at that time.
I don't believe that the error would be considered critical but if
it's something that needs to be fixed, I wanted to get the report out
ASAP.
--
Mr. F Harvell
First Time Software
407 467-1919
On 10 Dec 2005, at 23:59, Marc G. Fournier wrote:
7.3.12, 7.4.10, 8.0.5 and 8.1.1 ... all should be available on the
ftp mirrors by now ... please take a quick peak at them, and let us
know if there appear to be any problems with them ...
General announce of availability going out on monday ...
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Postgres Crashes
This sounds very much like a memory problem. I would replace all of the memory with another set of (preferably known good) memory and see if the problems persist. Also look for other cores that may be dropped. If there are several, memory is the likely cause. Be aware that it will likely be active, large memory applications (of which PostgreSQL may be the only one on the server) that will materialize the issues. Memory testing application may also show the problem, however, they do not test like production use. I have had test apps run for weeks where production use can cause failures in mere minutes. Also, note that I have seen issues with bad CPU's (bad cache?) that have caused similar problems. On 30 Apr 2004, at 15:24, Prem Gopalan wrote: We run a multithreaded application that uses postgres 7.4 on Linux 2.4.18, dual cpu Xeon processor machine. We have occassional weird crashes and have tried a lot of things to reproduce them in house, but in vain. We do have coredumps and I have listed the backtraces and their common characteristics here. ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] non-standard escapes in string literals
On Thu, 25 Apr 2002 15:07:44 EDT, Tom Lane wrote: > F Harvell <[EMAIL PROTECTED]> writes: > > This also poses the biggest problem in terms of legacy compatibility. > > Perhaps the answer is to add a runtime config option (and default it > > to ANSI) and possibly deprecate the C escaping. > > While I wouldn't necessarily object to a runtime option, I do object > to both the other parts of your proposal ;-). Backslash escaping is > not broken; we aren't going to remove it or deprecate it, and I would > vote against making it non-default. > Sorry, didn't mean to imply that backslash escaping was broken, just non-compliant. Beyond that, your recommendations are also probably the best course of action. I do desire that the "default" operation of the database be as ANSI standard compliant as possible, however, I certainly understand the need to be as backwards compliant as possible. The only issue that I can see with keeping the backslash escaping default is that new, non-PostgreSQL programmers will not be expecting the escaping and will be potentially blindsided by it. (A bigger deal since backslashes are unusual and are not often tested for/with.) Perhaps prominent notice in the documentation will be adequate/appropriate. Maybe a section on differences with the ANSI standard should be created. (Is there currently a compilation of differences anywhere or are they all dispersed within the documentation?). Thanks, F -- Mr. F Harvell Phone: +1.407.673.2529 FTS International Data Systems, Inc.Cell: +1.407.467.1919 7457 Aloma Ave, Suite 302Fax: +1.407.673.4472 Winter Park, FL 32792 mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] non-standard escapes in string literals
On Thu, 25 Apr 2002 10:41:56 EDT, Bruce Momjian wrote: > Andrew Pimlott wrote: > > I posted this some time ago to pgsql-bugs[1], to no response. So > > I'll venture to try here. > > > > Postgres breaks the standard for string literals by supporting > > C-like escape sequences. This causes pain for people trying to > > write portable applications. Is there any hope for an option to > > follow the standard strictly? > > This is actually the first time this has come up (that I remember). We > do support C escaping, but you are the first to mention that it can > cause problems for portable applications. > > Anyone else want to comment? I don't know how to address this. IMHO, I agree that I would like to see the ANSI standard implemented. While I really like PostgreSQL, it currently does not scale as large as other DBMS systems. Due to this, we try to code as database agnostic as possible so that a port requires a minimum of effort. Currently there are only a few areas remaining that are at issue. (Intervals and implicit type conversion have/are being addressed). I believe that the reason that it hasn't come up as an issue, per se, is that it would only affect strings with a backslash in them. Backslash is not a commonly used character. In addition, MySQL, also broken, uses backslashes in the same/similar way. Lots of people using PostgreSQL are stepping up from MySQL. This also poses the biggest problem in terms of legacy compatibility. Perhaps the answer is to add a runtime config option (and default it to ANSI) and possibly deprecate the C escaping. Thanks, F Harvell -- Mr. F Harvell Phone: +1.407.673.2529 FTS International Data Systems, Inc.Cell: +1.407.467.1919 7457 Aloma Ave, Suite 302Fax: +1.407.673.4472 Winter Park, FL 32792 mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Again, sorry, caching.
On Tue, 19 Mar 2002 12:12:52 CST, "Ross J. Reedstrom" wrote: > On Mon, Mar 18, 2002 at 09:35:51PM -0500, Neil Conway wrote: > > > > > > "It is an application issue" > > > This is completely wrong. Caching can not be done against a database without > > > knowledge of the database, i.e. when the data changes. > > ... > > > > If we're looking to provide a "quick and easy" caching scheme for users > > attracted to MySQL's query cache, why not provide this functionality > > through another application? > > ... > > > > What does everyone think? > > Neil, this sounds like exactly the approach to follow up on: > ... > > Seems like a win all around. Anyone else have comments? > ... I'm not certain the full direction of the thinking here, however, it seems to me that there are a few considerations that I would like to see/keep in mind: I feel that the caching should be SQL transparent. If it is implemented reasonably well, the performance gain should be pretty much universal. Yes, a large number of queries would never be called again, however, the results still need to be fetched into memory and "caching" them for later reuse should involve little more than a skipped free (think filesystem cache). It makes more sense to specify "non-cachable" in a query for tuning than "cacheable". This also means that just switching databases to PostgreSQL improves my performance. Also, it is very important that the caching should be transparent to the application. This means that the application should be able to connect to the database using the "standard" application interface (i.e., ODBC, PHP, Perl/DBI, etc.) This allows me to port my existing Oracle/DB2/MySQL/etc. application to pgsql through normal porting. If I have to implement a non-standard interface, I can likely gain even more performance through custom code and maintain reasonable database independence. While I am a strong believer in PostgreSQL, many of my customers have other demands/requirements. I still want to be able to use my existing code and libraries when using their database. Sticking with the "standards" allows me to develop best of class applications and interface to best of class databases. It also allows others to easily realize the value of PostgreSQL. Thanks, F Harvell ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Unhappiness with forced precision conversion
On Fri, 05 Oct 2001 19:35:48 -, Thomas Lockhart wrote: > ... > > Have you actually used ANSI SQL9x time zones? istm that "one offset fits > all" is really ineffective in supporting real applications, but I'd like > to hear about how other folks use it. Fortunately, most of our date/time information is self-referential. I.e., we are usually looking at intervals between an initial date/ timestamp and the current date/timestamp. This has effectively eliminated the need to deal with time zones. > > In this case, I believe that it would be preferable to stick with the > > TIME(0) and TIMESTAMP(6) default precision. In our applications, we > > always specify the precision, so, the default precision is not a real > > concern for us, however, for portability, I still suggest sticking > > with the standard. > > We are likely to use the 0/6 convention for the next release (though why > TIME should default to zero decimal places and TIMESTAMP default to > something else makes no sense). The only thing that I can think of is that originally, the DATE and TIME types were integer values and that when the "new" TIMESTAMP data type was "created" the interest was to increase the precision. I would guess, as you have also suggested, that the standards were based upon existing implementations (along with an interest in backwards compatibility). Thanks, F Harvell ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Unhappiness with forced precision conversion
We use timestamps and intervals quite a bit in our applications. We also use several different databases. Unfortunately, the time/date/ interval area is one that is not at all consistent between databases. It makes life particularly difficult when trying to re-use application code. So far, as compared to many other databases, PostgreSQL, remains pretty close to the standard (at least for our projects). The only areas that we have had issues with is the default inclusion of the timezone information when retriving the timestamp information and the slightly non-standard interval literal notation (i.e., including the year-month or day-time interval information inside the single quotes with the literal string). My vote on all datetime questions is to stick strictly to the standard. Of course sticking to the standard is not always easy as the standard is not always clear or even consistent. (I'm only familiar with ANSI 92 not ANSI 99.) Time zones in particular seem to be problematic. In this case, I believe that it would be preferable to stick with the TIME(0) and TIMESTAMP(6) default precision. In our applications, we always specify the precision, so, the default precision is not a real concern for us, however, for portability, I still suggest sticking with the standard. Thanks, F Harvell On Thu, 04 Oct 2001 20:30:24 -, Thomas Lockhart wrote: > > The code asserts that SQL99 requires the default precision to be zero, > > but I do not agree with that reading. What I find is in 6.1: > > 30) If is not specified, then 0 (zero) is implicit. > > If is not specified, then 6 is implicit. > > so at the very least you'd need two different settings for TIME and > > TIMESTAMP. But we don't enforce the spec's idea of default precision > > for char, varchar, or numeric, so why start doing so with timestamp? > > Sure, I'd forgotten about the 6 vs 0 differences. Easy to put back in. > One of course might wonder why the spec *makes* them different. > > "Why start doing so with timestamp?". SQL99 compliance for one thing ;) > > I'm not sure I'm comfortable with the spec behavior, but without a > discussion I wasn't comfortable implementing it another way. > > > Essentially, what I want is for gram.y to set typmod to -1 when it > > doesn't see a "(N)" decoration on TIME/TIMESTAMP. I think everything > > works correctly after that. > > "... works correctly..." == "... works the way we'd like...". Right? > > This is the start of the discussion I suppose. And I *expected* a > discussion like this, since SQL99 seems a bit ill-tempered on this > precision business. We shouldn't settle on a solution with just two of > us, and I guess I'd like to hear from folks who have applications (the > larger the better) who would care about this. Even better if their app > had been running on some *other* DBMS. Anyone? > > - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
