Re: [HACKERS] casting for dates
Will SELECT now() - 'nummonths months'::interval ; work? - Original Message - From: Vince Vielhaber [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 4:30 PM Subject: [HACKERS] casting for dates I'm trying to use an integer from a table to add/subtract time in months. IOW: create table foo(nummonths int); select now() - nummonths months; So far nothing I've tried will work - short of a function. Is there a way to do this? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Escaping strings for inclusion into SQL queries
Perhaps I'm not thinking correctly but isn't it the job of the application that's using the libpq library to escape special characters? I guess I don't see a down side though, if it's implemented correctly to check and see if characters are already escaped before escaping them (else major breakage of existing application would occur).. I didn't see the patch but I assume that someone took a look to make sure before applying it. -Mitch - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Florian Weimer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 6:43 PM Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries Florian Weimer [EMAIL PROTECTED] writes: We therefore suggest that a string escaping function is included in a future version of PostgreSQL and libpq. A sample implementation is provided below, along with documentation. We have now released a description of the problems which occur when a string escaping function is not used: http://cert.uni-stuttgart.de/advisories/apache_auth.php What further steps are required to make the suggested patch part of the official libpq library? Will be applied soon. I was waiting for comments before adding it to the patch queue. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Escaping strings for inclusion into SQL queries
Ok, I misudnerstood, I had long included my own escaping function in programs that used libpq, I thought the intent was to make escaping happen automatically.. Thanks! -Mitch - Original Message - From: Alex Pilosov [EMAIL PROTECTED] To: Mitch Vincent [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 7:32 PM Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries It is. Application is responsible to call PGescapeString (included in the patch in question) to escape command that may possibly have user-specified data... This function isn't called automatically. On Thu, 30 Aug 2001, Mitch Vincent wrote: Perhaps I'm not thinking correctly but isn't it the job of the application that's using the libpq library to escape special characters? I guess I don't see a down side though, if it's implemented correctly to check and see if characters are already escaped before escaping them (else major breakage of existing application would occur).. I didn't see the patch but I assume that someone took a look to make sure before applying it. -Mitch - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Florian Weimer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 6:43 PM Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries Florian Weimer [EMAIL PROTECTED] writes: We therefore suggest that a string escaping function is included in a future version of PostgreSQL and libpq. A sample implementation is provided below, along with documentation. We have now released a description of the problems which occur when a string escaping function is not used: http://cert.uni-stuttgart.de/advisories/apache_auth.php What further steps are required to make the suggested patch part of the official libpq library? Will be applied soon. I was waiting for comments before adding it to the patch queue. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
MySQL has to first add some features in order to have some bugs, don't they? :-) Some people crack me up in their opinions.. If it took him 6 hours to figure out int8 then I'm not really interested in anything else he has to say... Lord... -Mitch - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 7:05 AM Subject: [HACKERS] Link to bug webpage If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: List response time...
I've had great luck with Postfix as well. -Mitch - Original Message - From: Ian Lance Taylor [EMAIL PROTECTED] To: Lamar Owen [EMAIL PROTECTED] Cc: Serguei Mokhov [EMAIL PROTECTED]; PostgreSQL Hackers [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 4:24 PM Subject: [HACKERS] Re: List response time... Note that the postgresql.org mail server is still running sendmail. In my personal experience with sources.redhat.com, qmail is a much better choice to handle large mailing lists. When we switched from sendmail to qmail, mailing list delays dropped from hours, or sometimes even days, to seconds. Ian ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PQexec() 8191 bytes limit and text fields
First, are you using the latest PG? I was under the impression that all the hard-coded limitations on size had been eliminated in the latest releases. I know for an absolute fact that I can insert multi-megabyte sized text chunks in PG 7.1.2 as I've done just that before... Good luck! -Mitch - Original Message - From: Steve Howe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 18, 2001 4:51 AM Subject: [HACKERS] PQexec() 8191 bytes limit and text fields Hello all, Writing my interface application, which use the PQexec library, I came across the PQexec() queries 8191 bytes limit. What useful are 4Gb text fields if I have this limit ? I mean, if a user make an update to this field, with a large value (let's say, 4Mb), do I have to call PQexec multiple (more then 500) times, concatenating the strings each time I call it ??? Can't this be better implemented ? This is too slow, and generates much more traffic then I ever wish. This problem also plagues the large objects API, since they're only a wrapper to the built-in large objects API. Does anyone have a better way of doing this ? Best Regards, Steve Howe http://www.vitavoom.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: [HACKERS - GENERAL] PQexec() 8191 bytes limit and text fields
Hi Steve, lets approach this from the other angle... I don't see anywhere in your email where you say what makes you think that you can only pass a query 8191 bytes in size to PG. What exactly makes you think that there is some hard coded limit? This limit is not in 7.1.2 so either you have outdated source code or the problem is somewhere else.. Good luck! -Mitch - Original Message - From: Steve Howe [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 18, 2001 1:30 PM Subject: Re: [HACKERS] PQexec() 8191 bytes limit and text fields Hi... The problem is, I compiled it myself from original PostgreSQL version 7.12 C sources using Microsoft's Visual C++ 6.0. I had to compile it because I add a function to free the handlers returned from PQnotifies(), or I would have a memory leak. The resulting libpq.dll seems ok in everything but this issue... I guess I'll do it again, after checking the sources :) Other people reported me they send large queries with no problems, so I guess it should really be a problem of mine... Best Regards, Steve Howe - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Steve Howe [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 18, 2001 1:14 PM Subject: Re: [HACKERS] PQexec() 8191 bytes limit and text fields Steve Howe [EMAIL PROTECTED] writes: Writing my interface application, which use the PQexec library, I came across the PQexec() queries 8191 bytes limit. You must have a very out-of-date library. Time to update. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: CRN article not updated
If _you_ had been deluged with that kind of vitriol, what kind of favors
would you feel like doing?
Well, one person's opinion on the article that was perhaps expressed a
little harshly shouldn't cause the company to cover their ears and hum when
their article is in need of multiple corrections (as pointed out by many people,
some involved professionally with PostgreSQL and some not).. I did go through
and read some other articles written by this author -- they're all pretty bad
and filled with half-researched statements.
The article also made it seems as if Great Bridge owned and developed
PostgreSQL, which is of course totally false. That stepped on some fingers I'm
*sure*.
It's too late. "We" screwed it up. (Thanks again, guys.)
The responses have done far more lasting damage than any article
could ever have done. The horse is dead.
There isn't really a "we", is there? The PostgreSQL community isn't any kind
of entity that can be governed.. Great Bridge and PostgreSQL INC are such
entites and I'm sure they both handled the situation differently than the people
that sent in their personal opinions..
The best we can do is to plan for the future.
1. What happens the next time a slightly inaccurate article is published?
The author and publisher will probably get flamed by angry PostgreSQL users,
demanding the article be corrected :-)
Regardless of it being right or good for the (commercial) success of
PostgreSQL, people will get pissed and express some pretty harsh opinions when
something they know and love is being insulted or otherwise attacked.
2. What happens when an openly hostile article is published?
See above, take result of above and cube the intensity factor. :-)
Will our posse ride off again with guns blazing, making more enemies?
Will they make us all look to potential users like a bunch of hotheaded,
childish nobodies?
Who is "we"? Even if we ("we" being you and I) come up with something we
think is best we can't force others to do what ever that may be. Result? Someone
is always going to get angry and let the person(s) attacking know what's on
their mind.
Or will we have somebody appointed, already, to write a measured,
rational, mature clarification? Will we have articles already written,
and handed to more responsible reporters, so that an isolated badly-done
article can do little damage?
Great Bridge and their marketing people will do this.. Maybe? After all,
the PostgreSQL users/developers don't have to market their product, they're not
selling anything! (I do know some of them now work for Great Bridge, though)
We're not even on Oracle's radar yet. When PG begins to threaten their
income, their marketing department will go on the offensive. Oracle
marketing is very, very skillful, and very, very nasty. If they find
that by seeding the press with reasonable-sounding criticisms of PG,
they can prod the PG community into making itself look like idiots,
they will go to town on it.
This is something for companies, like Great Bridge, to deal with and just
isn't an issue for the PostgreSQL development/user community as we're not
marketing anything :-)
After saying all that, let me say this.. I use PostgreSQL and have been
using it for several years now, I think it's the best RDBMS out there for me and
I have recommend (and used) it for every database-driven project I've done to
date. I haven't had any trouble convincing clients to use PostgreSQL over Oracle
(and everyone that wants some software written always wants to use Oracle!). I
present the facts of PostgreSQL and in every one of the cases I've been involved
in, PostgreSQL is simply the best choice, everyone ends up happy..
To all involved in the development of PostgreSQL : THANKS!
-Mitch
Life is good. Be happy.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Fast Forward (fwd)
To top it all off, their comments are broken -- I submitted mine and it displays Marc's again (until you click on the link of course).. *sigh* they must be using MySQL. :-) -Mitch - Original Message - From: "The Hermit Hacker" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 15, 2001 10:44 AM Subject: Re: Fast Forward (fwd) On Sat, 14 Apr 2001, Nathan Myers wrote: This is probably a good time to point out that this is the _worst_ _possible_ response to erroneous reportage. The perception by readers will not be that the reporter failed, but that PostgreSQL advocates are rabid weasels who don't appreciate favorable attention, and are favorable attention?? dangerous to write anything about. You can bet this reporter and her editor will treat the topic very circumspectly (i.e. avoid it) in the future. woo hoo, if that is the result, then I think Vince did us a great service, not dis-service ... Most reporters are ignorant, most reporters are lazy, and many are both. It's part of the job description. Getting angry about it is like getting angry at birds for fouling their cage. Their job is to regurgitate what they're given, and quickly. They have no time to learn the depths, or to write coherently about it, or even to check facts. Out of all the articles on PgSQL that I've read over the years, this one should have been shot before it hit the paper (so to say) ... it was the most blatantly inaccurate article I've ever read ... It will be harder than the original mailings, but I urge each who wrote to write again and apologize for attacking her. In a way, I think you are right .. I think the attack was aimed at the wrong ppl :( She obviously didn't get *any* of her information from ppl that belong *in* the Pg community, or that have any knowledge of how it works, or of its history :( ---(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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] The Current Release Docs
The "Current Release Docs" on the PostgreSQL website still look 7.0.Xish.. Just an FYI... -Mitch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Estimating Size of Database
In the FAQ.. http://www.postgresql.org/docs/faq-english.html#4.7 Good luck! -Mitch Software development : You can have it cheap, fast or working. Choose two. - Original Message - From: "Mitesh Shah" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 6:10 PM Subject: Estimating Size of Database Is there a Web site or some info somewhere that tells you how to estimate the size of your database. I know what my schema is and how many records will be in each table (but non have been inserted yet). How can I project how much disk space I will need for the database? Thanks! Mitesh ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Speaking of Indexing... (Text indexing)
Hmm. I'm pretty sure that a single index on the entire contents of a resume *as a single field* is close to useless. And an index on an 8k piece is also useless. Presumably you really want an index covering each significant word of each resume, in which case you would not run into the 4k limit (or 2k limit? it is documented somewhere) on the size of an *index* field (which is still a limitation on PostgreSQL built with the standard 8k block size. Of course, you can build with a larger block size). Just an FYI.. I asked the other day and someone (Tom?) told me it was about 2k.. -Mitch ---(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
[HACKERS] Re: why the DB file size does not reduce when 'delete'the data in DB?
I know your situations, your DB is not updated and inserted lots of records in few minutes, mine is difference, I have a real time Stock Trading system, you know, stock, its price is changed every minute or even every second , I need update and insert delta change into DB, draw their trend graphics, suppose there are 3000 stocks in market, there maybe 9000 records changed and inserted in one minutes, because PGSQL's storage manager problem( it does not reuse deleted record space), in 4 hours trading period, my harddisk can be full filled. because in the period, the table indeed gets very large, doing VACCUME is impossible in realtime, it will lock out other clients too long time, my point of view is PGSQL is fit for static or small changed database, not fit for lots of change in short time. It's admitadly a problem so I don't think you need to convince everyone that it's not the best way to handle things :-) I hate to say it, but your options currently are to upgrade your storage device or change databases... I think I'd fork out some cash for some new hardware verses buying a commercial database or putting up with the missing features of MySQL.. All my humble opinion of course, I wish you the best of luck. -Mitch ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: http access to ftp.postgresql.org files
Just an FYI -- It works well from behind my proxy.. -Mitch - Original Message - From: "Vince Vielhaber" [EMAIL PROTECTED] To: "Zeugswetter Andreas SB" [EMAIL PROTECTED] Cc: "'The Hermit Hacker'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 26, 2001 7:53 AM Subject: Re: http access to ftp.postgresql.org files On Mon, 26 Feb 2001, Zeugswetter Andreas SB wrote: I am having some problems with our proxy server (wget times out on header) and would like to know whether it would be possible to install http access to the snapshots and other download files ? This would probably also benefit others, no ? See if this works: http://www.postgresql.org/ftpsite/ Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
[HACKERS] Re: beta5 ...
I have a bunch of machines here, some are rather old (K6-200s,P133s, some 486s etc) but they're just collecting dust now. I would be more than happy to install any OS and do build testing for PostgreSQL is there is a need.. What OSes need to have PostgreSQL built/tested on that the developers don't have access to? If I can get the OS (and install it), I would be happy to dedicate those machines to PG build testing.. I could set them up on the network here (proxy, cable modem) or at the office (T1) and give developers access if needed too. I have several FreeBSD boxes running PG beta 4 now, but I'd bet at least one of you is using FreeBSD (and it compiles and installs rather nicely anyway).. -Mitch
[HACKERS] PostgreSQL - PHP problem
This is the debug output for the last query that seems to be throwing PHP
into a fit (a fit that somehow closes the backend connection - note, it
doesn't crash, it just closes)..
I don't think anything is going on here that shouldn't be, it looks the same
as any other query that succeeds.. I just wanted someone that could actually
read and understand this to take a look..
Thanks!
Debug output follows ---
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: SELECT * FROM app_degrees
parser outputs:
{ QUERY :command 1 :utility :resultRelation 0 :into :isPortal false
:isBinary false :isTemp false :unionall false :distinctClause :sortClause
:rtable ({ RTE :relname app_degrees :ref { ATTR :relname app_degrees
:attrs } :relid 660864 :inh false :inFromCl true :inJoinSet true :skipAcl
false}) :targetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23
:restypmod -1 :resname degree_id :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM
:resno 2 :restype 1043 :restypmod 14 :resname abbr :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 2
:vartype 1043 :vartypmod 14 :varlevelsup 0 :varnoold 1 :varoattno 2}} {
TARGETENTRY :resdom { RESDOM :resno 3 :restype 1043 :restypmod 54 :resname
description :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr
{ VAR :varno 1 :varattno 3 :vartype 1043 :vartypmod 54 :varlevelsup 0
:varnoold 1 :varoattno 3}}) :qual :groupClause :havingQual :hasAggs
false :hasSubLinks false :unionClause :intersectClause :limitOffset
:limitCount :rowMark }
after rewriting:
{ QUERY
:command 1
:utility
:resultRelation 0
:into
:isPortal false
:isBinary false
:isTemp false
:unionall false
:distinctClause
:sortClause
:rtable (
{ RTE
:relname app_degrees
:ref
{ ATTR
:relname app_degrees
:attrs
}
:relid 660864
:inh false
:inFromCl true
:inJoinSet true
:skipAcl false
}
)
:targetlist (
{ TARGETENTRY
:resdom
{ RESDOM
:resno 1
:restype 23
:restypmod -1
:resname degree_id
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}
:expr
{ VAR
:varno 1
:varattno 1
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 1
:varoattno 1
}
}
{ TARGETENTRY
:resdom
{ RESDOM
:resno 2
:restype 1043
:restypmod 14
:resname abbr
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}
:expr
{ VAR
:varno 1
:varattno 2
:vartype 1043
:vartypmod 14
:varlevelsup 0
:varnoold 1
:varoattno 2
}
}
{ TARGETENTRY
:resdom
{ RESDOM
:resno 3
:restype 1043
:restypmod 54
:resname description
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}
:expr
{ VAR
:varno 1
:varattno 3
:vartype 1043
:vartypmod 54
:varlevelsup 0
:varnoold 1
:varoattno 3
}
}
)
:qual
:groupClause
:havingQual
:hasAggs false
:hasSubLinks false
:unionClause
:intersectClause
:limitOffset
:limitCount
:rowMark
}
plan:
{ SEQSCAN :startup_cost 0.00 :total_cost 20.00 :rows 1000 :width 28 :state
:qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23
:restypmod -1 :resname degree_id :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM
:resno 2 :restype 1043 :restypmod 14 :resname abbr :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 2
:vartype 1043 :vartypmod 14 :varlevelsup 0 :varnoold 1 :varoattno 2}} {
TARGETENTRY :resdom { RESDOM :resno 3 :restype 1043 :restypmod 54 :resname
description :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr
{ VAR :varno 1 :varattno 3 :vartype 1043 :vartypmod 54 :varlevelsup 0
:varnoold 1 :varoattno 3}}) :qpqual :lefttree :righttree :extprm ()
:locprm () :initplan :nprm 0 :scanrelid 1 }
ProcessQuery
CommitTransactionCommand
proc_exit(0)
shmem_exit(0)
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 45155 exited with status 0
[HACKERS] Re: Like vs '='
There isn't any row or query size limit in 7.1 thanks to TOAST! -Mitch - Original Message - From: "Manuel Cabido" [EMAIL PROTECTED] To: "m w" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 29, 2001 10:18 PM Subject: Re: Like vs '=' Hi there, I am compiling postgresql 7.1beta4. How would i change the default 8k row limit? -- Manny C. Cabido e-mail:[EMAIL PROTECTED] [EMAIL PROTECTED] =
[HACKERS] Re: PostgreSQL - PHP problem
In the PHP bugs I see... ===[PostgreSQL related]=== 5862 Open Consecutive pg_open statements cause second statement to fail 6525 Open Connection problem 7007 Open The pg_close function doesn't close the connection. 7236 Open 1 is not a valid PostgreSQL link resource 7264 Open 1 is not a valid PostgreSQL link 7298 Open ... not a valid link resource... after pg_connect 7312 Open Problems with pg_connect() i pg_fetch_row() 7333 Open Connection fault in circled query 7529 Open pg_connect() returns invalid connection id 7536 Open Warning: is not a valid PostgreSQL link resource 7931 Feedback Undefined symbol "_PQconnectdb" 8053 Open PGSQL doesn't detects on FBSD4 8225 Open Suddenly doesnt allow multiple psql connections from one php page 8317 Open postgresql table uppercase field name 8689 Open pg_Connect() seems to do some type of caching that doesn't quite work 8769 Open Persistent connections aren't closed when using dynamically loaded module 8907 Open pg_Close on multiple connections to same host 9048 Open problem to open several connections on 4.0.4pl1 that worked on 4.0.2 Ouch. It looks like this is exactly what is happening to me. pg_open gets called several times in these scripts.. It looks like I'll have to install an old version of PHP.. Son of a er nevermind.. Thanks guys.. -Mitch
[HACKERS] Re: Re: PostgreSQL - PHP problem
Bruce said he and Rasmus (from PHP devel) were fixing this. That'll be great! -Mitch - Original Message - From: "Christopher Kings-Lynne" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 05, 2001 8:55 PM Subject: RE: Re: PostgreSQL - PHP problem I tell you what I'd like to see in PHP. If you're using a Postgres persistent connection, and it detects a 'BEGIN TRANSACTION' going thru, once that script has finished, the connection should not be returned to the connection pool. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mitch Vincent Sent: Tuesday, February 06, 2001 2:29 AM To: [EMAIL PROTECTED] Subject: [HACKERS] Re: PostgreSQL - PHP problem In the PHP bugs I see... ===[PostgreSQL related]=== 5862 Open Consecutive pg_open statements cause second statement to fail 6525 Open Connection problem 7007 Open The pg_close function doesn't close the connection. 7236 Open 1 is not a valid PostgreSQL link resource 7264 Open 1 is not a valid PostgreSQL link 7298 Open ... not a valid link resource... after pg_connect 7312 Open Problems with pg_connect() i pg_fetch_row() 7333 Open Connection fault in circled query 7529 Open pg_connect() returns invalid connection id 7536 Open Warning: is not a valid PostgreSQL link resource 7931 Feedback Undefined symbol "_PQconnectdb" 8053 Open PGSQL doesn't detects on FBSD4 8225 Open Suddenly doesnt allow multiple psql connections from one php page 8317 Open postgresql table uppercase field name 8689 Open pg_Connect() seems to do some type of caching that doesn't quite work 8769 Open Persistent connections aren't closed when using dynamically loaded module 8907 Open pg_Close on multiple connections to same host 9048 Open problem to open several connections on 4.0.4pl1 that worked on 4.0.2 Ouch. It looks like this is exactly what is happening to me. pg_open gets called several times in these scripts.. It looks like I'll have to install an old version of PHP.. Son of a er nevermind.. Thanks guys.. -Mitch
[HACKERS] Very odd order by behavior
FreeBSD 4.2, PostgreSQL 7.0.3 The attached file is the schema and data to the app_degrees table. Now check this out : select * from app_degrees gives (expected) : degree_id | abbr | description ---++-- 1818 | ACC| Accounting [ACC] 1819 | ACD| Acoustics [ACD] 1820 | ADV| Advertising [ADV] select * from app_degrees order by abbr ASC gives : degree_id | abbr | description ---++-- 1818 | ACC| Accounting [ACC] 1818 | ACC| Accounting [ACC] 1819 | ACD| Acoustics [ACD] 1819 | ACD| Acoustics [ACD] 1820 | ADV| Advertising [ADV] 1820 | ADV| Advertising [ADV] Either I'm seeing double or something isn't right here :-) Thanks for any insights. -Mitch
[HACKERS] Re: Very odd order by behavior - followup
I found the problem. User error, it's been a long Sunday. Sorry! -Mitch - Original Message - From: "Mitch Vincent" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 04, 2001 11:00 PM Subject: Very odd order by behavior FreeBSD 4.2, PostgreSQL 7.0.3 The attached file is the schema and data to the app_degrees table. Now check this out : select * from app_degrees gives (expected) : degree_id | abbr | description ---++-- 1818 | ACC| Accounting [ACC] 1819 | ACD| Acoustics [ACD] 1820 | ADV| Advertising [ADV] select * from app_degrees order by abbr ASC gives : degree_id | abbr | description ---++-- 1818 | ACC| Accounting [ACC] 1818 | ACC| Accounting [ACC] 1819 | ACD| Acoustics [ACD] 1819 | ACD| Acoustics [ACD] 1820 | ADV| Advertising [ADV] 1820 | ADV| Advertising [ADV] Either I'm seeing double or something isn't right here :-) Thanks for any insights. -Mitch
[HACKERS] Re: Format of the Money field
Just a question on this for my own personal satisfaction... What's the standard on Money type (if there is one) and if it doesn't include the $ (of course that would change based on what currency you were using) then is it any different than numeric(9,2)? numeric(9,2) is what I use for all fields that need to hold a dollar amount so I'm curious.. I remember reading in the documentation that money was numeric(9,2) with the dollar sign added but I wanted to check with the man :-) -Mitch - Original Message - From: "Peter Mount" [EMAIL PROTECTED] To: "Mitch Vincent" [EMAIL PROTECTED]; "The Hermit Hacker" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 03, 2001 5:50 AM Subject: Re: Format of the Money field At 12:07 02/02/01 -0500, Mitch Vincent wrote: hhs= select version(); version --- PostgreSQL 6.4.2 on i386-unknown-freebsd3.1, compiled by gcc 2.7.2. [snip] If it changed, it looks like it changed a long time ago! :-) Hmm, shows how many people use Money via JDBC then, as no one's reported it before. I only found out while testing JBuilder's interaction with the JDBC driver. Peter -Mitch - Original Message - From: "The Hermit Hacker" [EMAIL PROTECTED] To: "Peter T Mount" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 11:55 AM Subject: Re: Format of the Money field On Fri, 2 Feb 2001, Peter T Mount wrote: When did the MONEY type change it's output format? While working on the JDBC test suite, Money broke. It seems to output: $10.99 ($10.99) for negative values While since ages past, the PGMoney class interprets it as a number (no currency symbol). Looking over at Thomas and asking him, his recollection is that it always had the currency symbol ... but he's not 100% certain about that ... Can you confirm with the 7.0.3 server?
[HACKERS] Re: Re: Format of the Money field
I acknowledged the bad nature of the money field (pretty clearly stated in my email, I think).. I agree, it shouldn't contain a sign of anything.. My applications are used in the US and in the US only so I don't have issue with the currency symbol. I don't use the money type anyway (the example I used was from someone else's code!).. What I was actually asking about was the need for the money type, the same thing can be achieved using the other data types (in fact the documentation lists money as numeric(9,2) with the $ added I believe).. All that for exactly what you said, currency. There are as many currencies as countries (almost) so I totally agree, a symbol is A Bad Thing(TM).. You're also right (and bring up a good point) about the storing of money in the smallest unit if you're coding international... I haven't had to yet but it's something I'll be sure to do if it ever comes up.. Of course all this is moot, Peter already said he was changing it and that it shouldn't have been that way, it's just been overlooked (probably because no one is using the money type)! :-) I apologize to the list, I meant to send that email directly to Peter -- I was too quick on the send.. -Mitch - Original Message - From: "Dave Mertens" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 03, 2001 2:12 PM Subject: Re: Re: Format of the Money field On Sat, Feb 03, 2001 at 11:39:29AM -0500, Mitch Vincent wrote: What's the standard on Money type (if there is one) and if it doesn't include the $ (of course that would change based on what currency you were using) then is it any different than numeric(9,2)? numeric(9,2) is what I use for all fields that need to hold a dollar amount so I'm curious.. I remember reading in the documentation that money was numeric(9,2) with the dollar sign added but I wanted to check with the man :-) Oh, never heard of currency?? NOT every country is using dollars. In a few months we in Europe are going to use the Euro. A money-type is normaly a floating type with a precision of 5 (float(5)). A money field is just like an float, only less precies. By the way, storing money values with an decimal precision is a (mostly) a bad thing. We Save currency amounts in the smallest unit. We save every amount in Eurocents. Our programs format the amount to the proper format (US-format (35,673.56) or EuropeannFormat (35.673,56). Currency signs are bad things in databases. Most database are international, so most amounts also! Sorry for this hard correction. Dave Mertens System Administrator ISM, Netherlands [EMAIL PROTECTED]
[HACKERS] Re: Format of the Money field
hhs= select version(); version --- PostgreSQL 6.4.2 on i386-unknown-freebsd3.1, compiled by gcc 2.7.2. | currentsalary| money| 4 | hhs= select currentsalary from applicants; $77,000.00 $43,500.00 $0.00 $93,000.00 ... If it changed, it looks like it changed a long time ago! :-) -Mitch - Original Message - From: "The Hermit Hacker" [EMAIL PROTECTED] To: "Peter T Mount" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 11:55 AM Subject: Re: Format of the Money field On Fri, 2 Feb 2001, Peter T Mount wrote: When did the MONEY type change it's output format? While working on the JDBC test suite, Money broke. It seems to output: $10.99 ($10.99) for negative values While since ages past, the PGMoney class interprets it as a number (no currency symbol). Looking over at Thomas and asking him, his recollection is that it always had the currency symbol ... but he's not 100% certain about that ... Can you confirm with the 7.0.3 server?
[HACKERS] Beta 4 problem(s)
I've been using the 7.1 beta version for quite a while now and just upgraded to beta 4, I've noticed my application is reporting that the backend shuts down prematurely... (I'm using PHP).. I'm having a time trying to debug this.. I know it's not my code as this works fine on a 7.0.3 install.. I've upped my debug level to the max and don't see anything indicating that the backend crashed, so I'm at a loss.. In the PHP code, I just go to execute a query (after checking to make sure the value returned by pg_connect isn't 0) and I get a PHP warning "Warning: 1 is not a valid PostgreSQL link resource in ...". I'd like to figure this out, any pointers on what I might be able to do in the backend? It seems to be somewhat PHP related because I can take the individual queries and run them in psql just fine.. Are there any known issues in beta4 that might cause this kind of thing to happen? Are there any changes that anyone can think of that might need to happen to the PHP PostgreSQL support for 7.1? I'd be happy to look into doing making the changes if so.. Thanks!! -Mitch
[HACKERS] Re: Re: MySQL has transactions
When Postgresql 6.5 came out it, it was VERY MUCH better ( many many thanks to the developers and all involved). And I'm waiting for a solid 7.1 to fix that 8KB issue. Technically.. = BLCKSZ (can be up to 32k) I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions server) and haven't had a problem one.. -Mitch
[HACKERS] Beta 3 question(s)
Hey guys, I am just getting back into the swing of things (after a nice vacation and a not-so-nice move across country).. I just installed 7.1 Beta 3 and am playing with it (I'm impressed with the speed increase I've seen with virtually no tweaking BTW).. I see a lot of this when I'm importing data : DEBUG: copy: line 2865, XLogWrite: new log file created - try to increase WAL_FILES Is that anything to be concerned about? Do I need to increase WAL_FILES? If so, how? Thanks! -Mitch
Re: [HACKERS] beta testing version
Regardless of what license is best, could the license even be changed now? I mean, some of the initial Berkeley code is still in there in some sense and I would think that the original license (BSD I assume) of the initial source code release would have to be somehow honored.. I'm just wondering if the PG team could change the license even if they wanted to.. I should go read the license again, I know the answer to the above is in there but it's been a long time since I've looked it over and I'm in the middle of packing, so I haven't got the time right now.. Thanks to anyone for satisfying my curiosity in answering this question. I think that it's very, very good if the license is indeed untouchable, it keeps PostgreSQL from becoming totally closed-source and/or totally commercial.. Obviously things can be added to PG and sold commercially, but there will always be the base PostgreSQL out there for everyone.. I hope. Just my $0.02 worth.. -Mitch - Original Message - From: "Lamar Owen" [EMAIL PROTECTED] To: "PostgreSQL Development" [EMAIL PROTECTED] Sent: Tuesday, December 05, 2000 1:45 PM Subject: Re: [HACKERS] beta testing version The Hermit Hacker wrote: its been brought up and rejected continuously ... in some of our opinions, GPL is more harmful then helpful ... as has been said before many times, and I'm sure will continue to be said "changing the license to GPL is a non-discussable issue" ... I've declined commenting on this thread until now -- but this statement bears amplification. GPL is NOT the be-all end-all Free Software (in the FSF/GNU sense!) license. There is room for more than one license -- just as there is room for more than one OS, more than one Unix, more than one Free RDBMS, more than one Free webserver, more than one scripting language, more than one compiler system, more than one Linux distribution, more than one BSD, and more than one CPU architecture. Why make a square peg development group fit a round peg license? :-) Use a round peg for round holes, and a square peg for square holes. Choice of license for PostgreSQL is not negotiable. I don't say that as an edict from Lamar Owen (after all, I am in no position to edict anything :-)) -- I say that as a studied observation of the last times this subject has come up. I personally prefer GPL. But my personal preference and what is good for the project are two different things. BSD is good for this project with this group of developers -- and it should not change. And, like any other open development effort, there will be missteps -- which missteps should, IMHO, be put behind us. No software is perfect; no development team is, either. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] WAL information
Ok, this has peaked my interest in learning exactly what WAL is and what it does... I don't see any in-depth explanation of WAL on the postgresql.org site, can someone point me to some documentation? (if any exists, that is). Thanks! -Mitch - Original Message - From: "Nathan Myers" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 01, 2000 11:02 AM Subject: Re: [HACKERS] beta testing version On Fri, Dec 01, 2000 at 06:39:57AM -0800, Don Baccus wrote: Probably the best answer to the "what does WAL get us, if it doesn't get us full recoverability" questions is to simply say "it's a prerequisite to getting full recoverability, PG 7.1 sets the foundation and later work will get us there". Not to quibble, but for most of us, the answer to Don's question is: "It gives a ~20x speedup over 7.0." That's pretty valuable to some of us. If it turns out to be useful for other stuff, that's gravy. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] Size of my data base?
If you installed in the default directory then the files relating to a database are in /usr/local/pgsql/data/base/databasename So you could just total up the size of everything under that directory. -Mitch - Original Message - From: "Guus Kerpel" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 27, 2000 7:47 AM Subject: [HACKERS] Size of my data base? Hi everybody, there must be a nice way of getting the size of my database (in mB, preferably), but I couldn't find it in the documentation that I searched through briefly. The reason why I wanna do this is because the server might get full quickly and to make sure it doensn't happen before I know I'm writing a script that sends me the size of this database per mail. Can anyone direct me to an answer to this problem? I would be most thankful, Gus
Re: [HACKERS] beta testing version
No, WAL does help, cause you can then pull in your last dump and recover up to the moment that power cable was pulled out of the wall ... False, on so many counts I can't list them all. Why? If we're not talking hardware damage and you have a dump made sometime previous to the crash, why wouldn't that work to restore the database? I've had to restore a corrupted database from a dump before, there wasn't any hardware damage, the database (more specifically the indexes) were corrupted. Of course WAL wasn't around but I don't see why this wouldn't work... Note I'm not saying you're wrong, just asking that you explain your comment a little more. If WAL can't be used to help recover from crashes where database corruption occurs, what good is it? -Mitch
Re: [HACKERS] Please advise features in 7.1 (SUMMARY)
I guess it depends on what you're using it for -- disk space is cheap and abundant anymore, I can see some advantages of having it computed only once rather than X times, where X is the number of SELECTs as that could get costly on really high traffic servers.. Costly not so much for simple computations like that but more complex ones. Just playing the devil's advocate a bit. -Mitch - Original Message - From: "Zeugswetter Andreas SB" [EMAIL PROTECTED] To: "'Ross J. Reedstrom'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 7:50 AM Subject: AW: [HACKERS] Please advise features in 7.1 (SUMMARY) This is a summary of replies. 1. Calculated fields in table definitions . eg. Create table test ( A Integer, B integer, the_sum As (A+B), ); This functionality can be achieved through the use of views. Using a view for this isn't quite the same functionality as a computed field, from what I understand, since the calculation will be done at SELECT time, rather than INSERT/UPDATE. I would expect the calculated field from above example to be calculated during select time also, no ? You don't want to waste disk space with something you can easily compute at runtime. Andreas
Re: [HACKERS] Please advise features in 7.1 (SUMMARY)
So, having _both_ is the best thing. Absolutely, that's always what I meant -- we already have views and views can do this type of stuff at SELECT time can't they? So it's not a change, just an addition -Mitch
Re: [HACKERS] beta testing version
This is one of the not-so-stomped boxes running PostgreSQL -- I've never restarted PostgreSQL on it since it was installed. 12:03pm up 122 days, 7:54, 1 user, load average: 0.08, 0.11, 0.09 I had some index corruption problems in 6.5.3 but since 7.0.X I haven't heard so much as a peep from any PostgreSQL backend. It's superbly stable on all my machines.. Damn good work guys. -Mitch - Original Message - From: "The Hermit Hacker" [EMAIL PROTECTED] To: "Hannu Krosing" [EMAIL PROTECTED] Cc: "xuyifeng" [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Don Baccus" [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 8:53 AM Subject: Re: [HACKERS] beta testing version On Tue, 28 Nov 2000, Hannu Krosing wrote: xuyifeng wrote: I just noticed this conversation so I have not followed all of it, but you seem to have strange priorities I just want PG can be improved quickly, for me crash recover is very urgent problem, Crash avoidance is usually much more urgent, at least on production servers. Good call, but I kinda jumped to the conclusion that since PgSQL itself isn't that crash prone, its his OS or his hardware that was the problem :0
Re: [HACKERS] 8192 BLCKSZ ?
I've been using a 32k BLCKSZ for months now without any trouble, though I've not benchmarked it to see if it's any faster than one with a BLCKSZ of 8k.. -Mitch This is just a curiosity. Why is the default postgres block size 8192? These days, with caching file systems, high speed DMA disks, hundreds of megabytes of RAM, maybe even gigabytes. Surely, 8K is inefficient. Has anyone done any tests to see if a default 32K block would provide a better overall performance? 8K seems so small, and 32K looks to be where most x86 operating systems seem to have a sweet spot. If someone has the answer off the top of their head, and I'm just being stupid, let me have it. However, I have needed to up the block size to 32K for a text management system and have seen no performance problems. (It has not been a scientific experiment, admittedly.) This isn't a rant, but my gut tells me that a 32k block size as default would be better, and that smaller deployments should adjust down as needed.
Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections
I'm sure that this, if true, could certainly be the source of the problems I've seen... I can't comment on if PHP is completely threadsafe, I know that some of the modules (for lack of a better word) aren't, possible the ClibPDF library I'm using. I'll check into it. Thanks! -Mitch - Original Message - From: "Don Baccus" [EMAIL PROTECTED] To: "Mitch Vincent" [EMAIL PROTECTED]; "PostgreSQL Hackers List" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 25, 2000 9:18 PM Subject: Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections At 10:00 PM 11/25/00 -0800, Mitch Vincent wrote: I've tried quite a bit to use persistent connections with PHP (for over a year) and always the scripts that I try to use them with behave crazy... The last time I tried there were problems all over the place with PHP, variables getting overwritten, certain functions just totally breaking (date() to name one) and so on.. I know I'm not being specific but my point is that I think there are some other outstanding PHP issues that play into this problem as the behavior that I've seen isn't directly related to PostgreSQL but only happens when I use persistent connections.. I've heard rumors that PHP isn't thoroughly threadsafe, could this be a source of your problems? - Don Baccus, Portland OR [EMAIL PROTECTED] Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
Re: [HACKERS] Crash during WAL recovery?
Just speaking Russian and English both (to any degree) is absolutely amazing, put that on top of MVCC and WAL and we have Vadim, the smartest person alive! *grin* -Mitch - Original Message - From: "Mikheev, Vadim" [EMAIL PROTECTED] To: "'Don Baccus'" [EMAIL PROTECTED]; "Christopher Kings-Lynne" [EMAIL PROTECTED]; "PostgreSQL Development" [EMAIL PROTECTED] Sent: Tuesday, November 21, 2000 5:37 PM Subject: RE: [HACKERS] Crash during WAL recovery? Is there any particular reason the spelling and punctuation in the code snippet below is so bad? Vadim's Russian. This impacts his english but not his ability to implement complex features like MVCC and WAL :) Yes, sorry guys. C lang is much easier -:)) Vadim
Re: [HACKERS] RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL
I've wondered and am still wondering what a lot of these benchmark tests are out to prove. I'm not sure that any PostgreSQL advocate has ever said or implied that PostgreSQL is faster than anything, much less MySQL. While I'm sure it's faster than some, I've just never heard the argument for using PostgreSQL as "It's faster than anything else". I chose PostgreSQL by what it could do, not how fast it can SELECT... No benchmark between MySQL and PostgreSQL (or any other RDBMS ) is ever going to be truly accurate since there are so many things MySQL simply can't to that PostgreSQL (and others) can.. As Don often out often and accurately points out, MySQL is not an RDBMS, I'm not sure what it really is beyond a semi-fancy SQL interface to a file system.. Is it fast? Yes, it is pretty fast. Fast at the expense of functionality and stability -- two things that just aren't optional when you're talking about a good database for anything more complicated than click-through tracking... I don't dislike MySQL for any other reason except that it can't do what I need it to do, period... I'm sure it's good for some things and some people, I've tried MySQL, tested MySQL and then tossed MySQL into the garbage can... I found some very educational conversation here : http://openacs.org/philosophy/why-not-mysql.html courtesy of Don and others. -Mitch - Original Message - From: "Don Baccus" [EMAIL PROTECTED] To: "Robert D. Nelson" [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Michael Fork" [EMAIL PROTECTED]; "Poul L.Christiansen" [EMAIL PROTECTED] Cc: "pgsql-general" [EMAIL PROTECTED]; "pgsql-hackers" [EMAIL PROTECTED] Sent: Monday, November 20, 2000 8:48 PM Subject: Re: [HACKERS] RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL At 11:22 AM 11/13/00 -0500, Robert D. Nelson wrote: Still...Regardless of what database they're running, either their abstraction layer is shit or their queries really need optimized. Is that perhaps why, even at 5 clients, the page views he shows never went significantly above 10/sec? They don't appear to do any client-side query caching, which is understandable from one point of view (you need some sort of handle on which queries are hit frequently enough to warrant devoting RAM to caching the result, or else you risk caching things that don't gain you much and cut down on the amount of the DB cached in RAM which hits you on other queries). On the other hand, you'd think they'd do some analysis... Still, the table-locking of MySQL just gets in the way. If you can cache everything, then you can send a postal worker to the mailbox to retrieve uncached data without significantly impacting throughput (in other words, the MySQL argument that simple select benchmarks are all you need are not relevant). If you can't cache anything but have few users, then perhaps low levels of concurrency don't hurt. If you don't cache anything but have lots of users, scaling well under high levels of load rule. My thinking is that intellegent caching coupled with a highly-scalable database wins. That's the world I'm used to... - Don Baccus, Portland OR [EMAIL PROTECTED] Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
[HACKERS] 7.0.2 - 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i /usr/local/pgsql/postgres.log 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open() that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
Re: [HACKERS] 7.0.2 - 7.0.3 problem
By the way, what is pg_control and what does it do?
-Mitch
- Original Message -
From: "Michael Ansley" [EMAIL PROTECTED]
To: "'Mitch Vincent '" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, November 12, 2000 4:02 PM
Subject: RE: [HACKERS] 7.0.2 - 7.0.3 problem
You have to dump/initdb/reload if you change the block size. Simply
recompiling is not going to work.
Cheers...
MikeA
-Original Message-
From: Mitch Vincent
To: [EMAIL PROTECTED]
Sent: 11-13-00 12:57 AM
Subject: [HACKERS] 7.0.2 - 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i /usr/local/pgsql/postgres.log 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which
has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way
down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's
Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open()
that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and
start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone? - Fixed!
It wasn't PostgreSQL, it was me of course! Seeing as it was so long ago, I forgot that the BLCKSZ on the production server wasn't 32k, it was 31k (for whatever reason).. When I set the BLCKSZ lower than that and tried to start the backend it told me that the database was initialized with a BLCKSZ of 31k, strange that it didn't say that when I compiled with a BLCKSZ of 32k but regardless of all that it was my stupidity that was the problem, nothing more.. My apologies for wasting everyone's time, file this problem in the "stupid user" category. Thanks to all, I'm off to sit in the corner for a while... -Mitch - Original Message - From: "Bruce Momjian" [EMAIL PROTECTED] To: "Mitch Vincent" [EMAIL PROTECTED] Sent: Sunday, November 12, 2000 6:47 PM Subject: Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone? Quite strange. There isn't much in 7.0.3 that would cause that. [ Charset ISO-8859-1 unsupported, converting... ] You are correct. It does not need a dump/restore. Excellent, my apologies for not being clear before... Do you have any other ideas as to what might have caused this problem? -Mitch -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] off-topic: (sorta) freebsd - oracle, lightweight
I think it's against the Oracle license to run it under any kind of emulation (which is what you would have to do with FreeBSD, run it under Linux emulation).. All that's void if they support FreeBSD natively now (which I don't think they do).. Wouldn't this be a better question for an Oracle list since this has nothing to do with PostgreSQL? (Just a friendly suggestion) :-) Good luck!! -Mitch - Original Message - From: "Jim Mercer" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 02, 2000 12:43 PM Subject: [HACKERS] off-topic: (sorta) freebsd - oracle, lightweight i need to query some oracle tables from a freebsd system. is there a lightweight method to do this, or do i have no choice but to put in the Oracle Linux stuff and use their API's? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True ode. ]
