[GENERAL] "q" with psql display paging dumps out of psql
Hi, Environment: SunOS 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine Postgresql-7.4.6 Build config: --with-java --enable-thread-safety gcc version 3.3.1 less-381 readline-4.3 $ echo $PAGER /usr/local/bin/less $ echo $LESS -e I recently upgraded from 7.4.2 to 7.4.6 and have run into a new problem. As frequently as not, maybe even most times, when I "q" out of paging the output of a query in psql: Instead of just quitting that query, I get dumped straight out of psql. To add insult to injury: The command history for the current session isn't saved. (Only what was in the command history on entry.) It's really quite irritating :/. It's not repeatable. If I try to trace the psql session with truss, it doesn't do it. If I "G" to the end of the output and then "q", it doesn't do it. I down-graded to Postgresql-7.4.5. It happened with it. I upgraded "less" from v332 to v381. No improvement. "echo $?" after it happens yields "141." There is no "141" in /usr/include/sys/errno.h. I'm guessing it's some kind of race condition. Any suggestions where I might start debugging this problem? Jim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] "q" with psql display paging dumps out of psql
Tom Lane <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Jim Seymour) writes: > > I recently upgraded from 7.4.2 to 7.4.6 and have run into a new > > problem. As frequently as not, maybe even most times, when I "q" out > > of paging the output of a query in psql: Instead of just quitting that > > query, I get dumped straight out of psql. To add insult to injury: The > > command history for the current session isn't saved. > > "echo $?" after it happens yields "141." > > 141-128 = 13 = SIGPIPE. So psql is getting sigpipe'd. Yeah, a couple guys on one of my IRC channels figured that out. I subsequently smacked myself on the forehead and went "Doh!" (Been too many years away from systems coding, I guess.) > The question is > why? It is set up to ignore SIGPIPE everywhere that it could reasonably > expect to get it, in particular from writing to the pager. Dunno. > > > I'm guessing it's some kind of race condition. > > The timing condition involved is probably whether or not psql has > finished writing all of the query result to the pager before you > quit the pager. So if you retrieve a large query result and "q" > immediately you can probably make it more reproducible. I suppose anything's possible. But I usually look at the result for a bit after querying for it ;), so... Anyway, I tried it on a query that pretty reliably exhibits the problem, and no amount of waiting before hitting "q" seems to make any difference. By the way, I get this in the serverlog: "LOG: unexpected EOF on client connection". > > Also, I don't think we changed that stuff between 7.4.2 and 7.4.6 > (though I haven't trawled the commit logs to make sure). Was your > 7.4.2 installation also built with --enable-thread-safety? Yes, my 7.4.2 install was built with --enable-thread-safety. (In fact: If you check the archives, you'll see it was I discovered a problem with building with --enable-thread-safety in 7.4.2 and created a patch to fix it.) > It seems > likely that addition or removal of --enable-thread-safety would make > a difference. I was thinking of giving that a go, being as the only things I could see in the HISTORY that looked like they might have any relationship was "thread on Solaris" stuff. Sure enough, compiling without --enable-thread-safety makes the problem go away. Anything else I can try/answer for y'all? Jim ---(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: [GENERAL] pgEdit public beta for Macintosh and Windows
John DeSoi <[EMAIL PROTECTED]> wrote: > > The first public beta for pgEdit is now available ... [snip] > > * Cross platform and easy to install > > pgEdit is a native application for both Macintosh and Windows. That's what you call "cross-platform," eh? >It does > not use Java ... [snip] This is supposed to be an advantage? Ah well, I don't use Mac or Windows, so I guess we're even ;). Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Bug in queries ??
"Joost Kraaijeveld" <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
>
> I have three questions about 1 table
>
> CREATE TABLE public.logs
> (
> rule_name varchar(32) NOT NULL,
> bytes int8 NOT NULL,
> pkts int8 NOT NULL,
> hostname varchar(100),
> that_time int4 NOT NULL
> ) WITH OIDS;
>
> Question 1.
>
> If I run the following query:
>
> select cast(min(that_time) as abstime), cast(max(that_time) as abstime),
> (sum(bytes)/(1024*1024)) as "Totaal in Megabytes" from logs
> where
> that_time between cast( abstime('2004-10-1 00:00') as int4) and
> cast( abstime('2004-11-1 00:00') as int4)
> and
> rule_name = 'Incoming 83 50 in' or
> rule_name = 'Outgoing 83 50 out'
>
> I expect that the outcome will be between "2004-10-1 00:00" and
> "2004-11-1 00:00" (the month october). However, I get the following result:
>
> min max Totaal in Megabytes
> "2004-09-01 00:00:01+02" "2004-11-23 11:50:01+01"; "82768.623353004456"
>
> The min date is the date of the first entry ever, the max entry the
> last entry ever. Why is this?
Because you're asking "between 1st date and second date and rule_name
equals something," OR rule_name equals something_else.
What you have is equivilent to
where (that between ... and ... and rule = ...) or rule = ...
You want
where time between ... and ... and (rule = ... or rule = ...)
>
>
> Question 2.
>
> If I refrase the above query to:
>
> select cast(min(that_time) as abstime), cast(max(that_time) as abstime),
> (sum(bytes)/(1024*1024)) as "Totaal in Megabytes" from logs
> where
> rule_name = 'Incoming 83 50 in' or
> rule_name = 'Outgoing 83 50 out'
> and
> that_time between cast( abstime('2004-10-1 00:00') as int4) and
> cast( abstime('2004-11-1 00:00') as int4)
>
> I get a diffent answer (see the Totaal in Megabytes):
>
> min max Totaal in Megabytes
> "2004-09-01 00:00:01+02" "2004-11-23 12:00:01+01" "92406.07880896"
>
> My question why is this?
You have
where rule = ... or (rule = ... and time between ...)
>
> Question 3.
>
> Querying for just "rule_name = 'Incoming 83 50 in'" gives 34990
> Megabytes, just querying for "rule_name = 'Outgoing 83 50 out'" gives
> 5524 Megabytes. How does that compare to the queries above?
The answer is probably clear by now ;).
Jim
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Upcoming Changes to News Server ...
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > > > Due to recent action by Google concerning the comp.databases.postgresql.* > hierarchy, we are going to make some changes that should satisfy just > about everyone ... over the next 24hrs or so, traffic *to* > comp.databases.postgresql.* from the mailing lists will cease and be > re-routed to pgsql.* instead ... on our server (and we encourage others to > do the same), the comp.* groups will be aliased to the new pgsql.* > hierarchy, so that posts to the old groups will still get through ... > > In order to improve propogation, as always, we welcome anyone wishing to > carry these groups to email [EMAIL PROTECTED] to get added on as a direct > peer ... Mark, No offense intended, but you already made one mistake by gating these mailing lists into the big-8 hierarchy, then allowing them to be propagated off whatever newserver to which that was done, into the general newsfeed, w/o going through the big-8 newsgroup creation process. Now somebody's trying to fix that by going through the process to legitimize comp.databases.postgresql.*, there is an RFD posted, and you're going to up and create pgsql.*? Did you warn the proponent of comp.databases.postgresql.* that you were going to do this? Did you read any of the arguments for and against a completely separate hierarchy that were posted to the RFD thread in news.groups? Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Upcoming Changes to News Server ...
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > [I had written] > > > > Did you warn the proponent of comp.databases.postgresql.* that you were > > going to do this? Did you read any of the arguments for and against a > > completely separate hierarchy that were posted to the RFD thread in > > news.groups? > > Interesting point. What did come of all the arguments? The current RFD thread is still active. (In news.groups, anyway.) This is how the big-8 newsgroup creation process usually works. New RFDs are posted, and discussion ensues, until it's decided it's time for a vote or the proponent(s) drop the idea. This can take some time. >These news server > changes seem to be fairly arbitrary and one lined. I'm going to *guess* the idea came from this comment: | Subject: Re: RFD: comp.databases.postgresql.* | Newsgroups: news.groups,comp.databases.postgresql.general | Date: 23 Nov 2004 11:50:42 GMT | Organization: Beaver Dam | From: Woodchuck Bill <[EMAIL PROTECTED]> | [snip] | | If they were to start their own hierarchy postgresql.*, they could keep all | 21 of the groups, all of the groups would be available upon request to news | servers around the world, Google would pick them up again in a heartbeat, | they would not need to pass a vote, and PostgreSQL would have even more | prestige by having a dedicated net news hierarchy. | [snip] | | Something to think about, Marc. The key words there being "think about," IMO. For example, the part about "would have even more prestige." Really? My news server at work doesn't carry such newsgroups at all. Which is pretty much the point somebody else made to a similar suggestion. (I.e.: Propagation might be poor.) >Perhaps this should > be taken up as a whole? [snip] I'm not clear on what exactly "as a whole" means, but I would suggest that arbitrary and peremptory behaviour, perceived or real, is not likely to endear the pgsql community to Usenet newsmasters. Jim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Upcoming Changes to News Server ...
Patrick B Kelly <[EMAIL PROTECTED]> wrote: > [snip] > > Marc appears to be the only one NOT making this situation worse. Appearances can be deceiving--particularly when you're unfamiliar with the territory. > Let's > review. Since Mike Cox's unsolicited attempt to "fix" a problems that > he perceived, what has happened? The list has been deluged with > countless angry process oriented messages filled with vitriol and > devoid of any content regarding the purpose of this forum, we have been > bombarded with profanity, This is Mike's fault, is it? This is the fault of somebody stepping up and *trying* to DTRT? What a... fascinating POV. > and the lists have been dropped from google. And other news servers. Do you know *why* that happened? Perhaps if you followed the RFD thread in news.groups, you would. Yes, it is likely that the RFD has brought to the attention of those webmasters who weren't aware that comp.databases.postgresql.* were bogus, and so they dropped them. Any one person could have single-handedly accomplished the same thing by raising hell in the proper venues. Do you know that some major Usenet news systems never carried comp.databases.postgresql.*, in the first place, because the hierarchy was bogus? Here's another factoid for you. When a new big-8 newsgroup is approved, an "official" newsgroup creation control message is sent. Well, somebody *forged* just such a control message for one-or-more comp.databases.postgresql.* newsgroups. > This seems like it was a fool's errand from the beginning and Marc has > done nothing but try to cooperate to the extent reasonable. Hate to say it, but from where I sit it looks you have every single point you made above wrong. But I'm not going to beat up Marc about it. I'm going to assume it's unfamiliarity with the way Usenet works. > That does > not include jumping through every hoop that anyone holds up for him. I hope your attitude does not reflect that of the general pgsql community, much-less that of the core development team. It sounds very un-pgsql-like to me. > [snip] > > I will not speak for Marc but say that as a member of the mailing list, > I think he does an excellent job of advocating the best interests of > the postgres community and I support his decisions. You can make any > accusations you like but we know what a good job Marc does and > appreciate Marc's efforts on our behalf. PostgreSQL is not an island unto itself. Just as the project is bound to abide by committee decisions wrt the SQL language, *if* it wants to be (relatively?) "standard," it's obliged to do the same in being part of the greater Usenet community. That is: *If* the pgsql community wishes to be part of the larger Usenet community. (Those of you who've been on Usenet for a while can stop laughing about the "Usenet community" thing, too ;).) Jim ---(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: [GENERAL] Upcoming Changes to News Server ...
"Gary L. Burnore" <[EMAIL PROTECTED]> wrote: > [snip] > > It's ok. Mysql's better anyway. Was that absolutely necessary? Jim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Upcoming Changes to News Server ...
Tom Lane <[EMAIL PROTECTED]> wrote: > [snip] > > Personally I think Marc should have waited awhile longer to see whether > the news.groups process would produce a positive vote, but that's just > my own $0.02. That's the way *I* would've preferred to see it handled. Then again: *I* was looking forward to the pgsql discussions widely propagated in Usenet. Others may not care. >He may well have decided that that wasn't going anywhere. > The part of the discussion that has reached this list certainly has not > given one cause to think it will :-( Au contraire. It looked to me like the general attitude was "Well, some wrong stuff happened, but now that they've been around as long as they have, where they have, maybe best to just let 'em become real." Jim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Upcoming Changes to News Server ...
"\"Marc G. Fournier From\"@svr1.postgresql.org"@linxnet.com: <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Jim Seymour) writes: > > >Here's another factoid for you. When a new big-8 newsgroup is > >approved, an "official" newsgroup creation control message is sent. > >Well, somebody *forged* just such a control message for one-or-more > >comp.databases.postgresql.* newsgroups. > > That was *not* done by myself, at any time ... several years back, I created > the groups, opened news.postgresql.org to the public, and lt the groups go > out through my feeds, but at *no point* did I send out a cmsg newgroup on > the groups themselves ... Didn't say you did, Marc. Didn't mean to so much as imply it was you. If that's the way it came across: Please accept my apologies. Hadn't even occurred to me it might have been you. Had they been signed by you: Sure. But, tho I don't know you, somehow I can't imagine you forging approvals for bogus newsgroups. If I were a gambling man, my bet would be on somebody that wanted to see the bogus newsgroups on whatever they had for news service. I wonder if it worked? Anyway, I was just pointing-out that one-or-more forged cmsg's were sent, that the person to whom I replied might better understand just how messed-up things were. Jim ---(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: [GENERAL] pg_dumpall + restore = missing view
"Thomas F.O'Connell" <[EMAIL PROTECTED]> wrote: > > For the record, you shouldn't have needed to do a dump restore between > 7.4.1 and 7.4.6 should you? IIRC, it was 7.4.1 -> 7.4.2 that required either that or some manual fixing-up. Jim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] off Topic: Looking for a good sql query
Jamie Deppeler <[EMAIL PROTECTED]> wrote: > > Hi, > > This post is a bit off topic im looking a good sql book can someone give > me a recommendation? I was pleased with... The Practical SQL Handbook Third Edition Judith S. Bowman, Sandra L. Emerson, & Marcy Darnovsky Addison-Wesley Developers Press A Division of Addison Wesley Longman, Inc. ISBN: 0-201-44787-8 (softcover, incl. CD-ROM) There's a 4th Edition out now. Here's Bookpool's listing: http://www.bookpool.com/.x/mrbet2p3z1/ss?qs=The+Practical+SQL+Handbook&x=0&y=0 I'm toying with the idea of selling, donating or trading-in my 3rd edition and picking-up the 4th. Jim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] [HACKERS] Adding Reply-To: to Lists configuration ...
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > > > What is the general opinion of this? I'd like to implement it, but not so > much so that I'm going to beat my head against a brick wall on it ... The procmail rules I set up for each mailing list to which I subscribe sets Reply-To to the mailing list *unless* there's already a Reply-To set. If you're going to do it, that's what I'd recommend doing. Jim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Adding Reply-To: to Lists configuration ...
Chris Green <[EMAIL PROTECTED]> wrote: > > On Sun, Nov 28, 2004 at 07:34:28PM -0400, Marc G. Fournier wrote: > > > > What is the general opinion of this? I'd like to implement it, but not so > > much so that I'm going to beat my head against a brick wall on it ... > > > Personally I'm against it because it means that I'll often get two > replies when people reply to my postings. However it's not a big > issue for me. Actually, it would result in just the opposite. Jim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Adding Reply-To: to Lists configuration ...
Chris Green <[EMAIL PROTECTED]> wrote: > > On Thu, Dec 02, 2004 at 01:59:07AM -0500, Greg Stark wrote: > > > > > > (On that note I would dearly love to get rid of the stupid "[GENERAL]" > > "[HACKERS]" etc tags? ... [snip] > > > I absolutely agree I hate the damn things with a passion. >and I've implemented a quick fix using my procmail > recipes:- > > :0 fh > * ^TOpostgres > | sed 's/\[GENERAL\]//' > :0 A: > postgres I like this better (for if you're on more than one pgsql list): :0 fh * [EMAIL PROTECTED] |perl -p -e 's/\[(ADMIN|GENERAL|HACKERS)\] //og' Plus it has the added advantage of dealing with things like, oh, say "Subject: Re: [GENERAL] [HACKERS] ..." ;) > > I now get to see more of the subject without the distraction of > [GENERAL] stuck in the middle of it! :-) Yup :) Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Basix for Data General / Basix for Sco Unix
Andrew Ayers <[EMAIL PROTECTED]> wrote: > [snip] > > What is "Basix" - didn't DG at one time make a PICK system (?) - There was a Pick operating system. Still is, actually. It had nothing to do with Data General. "Basix," I don't recall. > are you > sure that you are referring to a PICK Basic code? If this is what you > are referring to, then look into the keywords Pick, D3, UniVerse, and > multivalue. UniVerse is a dbm system that was derived from the Pick operating system, IIRC. I actually was nearly a UniVerse DBA. Until the company for which I worked at the time ran out of money before finishing the deployment of their new ERP system. Took classes at a place called JES. -- Jim Seymour| Spammers sue anti-spammers: [EMAIL PROTECTED] | http://www.LinxNet.com/misc/spam/slapp.php http://jimsun.LinxNet.com | Please donate to the SpamCon Legal Fund: | http://www.spamcon.org/legalfund/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] ident authentication problem
> > Jim Seymour wrote: > > Karsten Hilbert <[EMAIL PROTECTED]> wrote: > >>If you follow this sage advice you'll open up your financial > >>data to anyone happening to have an account on the machine in > >>question. Anyone. Not just people who also happen to have > >>*PostgreSQL* DB accounts. > > > > [snip] > > > > How, exactly, is that? > > The magic is in the -U flag for psql: > > psql -U pg_superuser any_db *Argh*! /me slaps self on forehead. Of course! Jim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] [OT] Tom's/Marc's spam filters?
> [snip] > > I think I looked into this a while ago and couldn't figure out a way to > discard a message from my MX without downloading it. Any ideas out > there? The problem is, again, as I noted earlier, this also breaks the mail system. Would you really trust blind blocking by IP address not to suffer the occasional false positive? It's bad enough when a FP causes a reject but, at least then, the legitimate sender gets the bounce and *knows* their email wasn't delivered. If you throw email that some rule says you don't want into the bit-bucket, that feedback goes away. IOW: It breaks the mail system. > > The sendmail code looks like: [snip] > /me doesn't do sendmail. (One of the first things I replace on every install I do, as a matter-of-fact.) The MTA I use (Postfix) would allow me to specify DISCARD, after a rule, to accomplish this. But, again, your backup MX is probably doing no more for you than causing you to agonize over which different way to break the mail system or irritate unwitting, innocent 3rd parties ;). Better to just rid yourself of the backup MX, IMO. -- Jim Seymour| Spammers sue anti-spammers: [EMAIL PROTECTED] | http://www.LinxNet.com/misc/spam/slapp.php http://jimsun.LinxNet.com | Please donate to the SpamCon Legal Fund: | http://www.spamcon.org/legalfund/ ---(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: [GENERAL] set autocommit TO FALSE on postgres 7.4
> > Dear Friends > > As Subject > > How to resolve, since i use with out problem on postgresql 7.3 Don't know, being as I know I've turned off autocommit within Perl, and I'm *fairly* sure I've done so playing around with psql, and it's worked as expected. -- Jim Seymour| Spammers sue anti-spammers: [EMAIL PROTECTED] | http://www.LinxNet.com/misc/spam/slapp.php http://jimsun.LinxNet.com | Please donate to the SpamCon Legal Fund: | http://www.spamcon.org/legalfund/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Multiple databases on seperate drives/file systems?
"Scot L. Harris" <[EMAIL PROTECTED]> wrote: > [snip] > > Yes I have tried it without quoting the PGDATA2. Same result. > > I have also tried the full path but the flag is apparently not set to > allow that. > > Besides the error I am getting it appears to me that postmaster would > not be able to find this new location for the new database. From > looking at the startup script in init.d it looks like it has PGDATA hard > coded and I did not see any place in the other config files to specify > additional database locations. > > It seems like I am missing a piece of the puzzle. Perhaps the man pages are screwed-up? $ man createdb [snip] -D location --location location Specifies the alternative location for the database. See also initlocation(1). $ man initlocation [snip] EXAMPLES To create a database in an alternate location, using an environment variable: $ export PGDATA2=/opt/postgres/data Stop and start postmaster so it sees the PGDATA2 environment variable. The system must be configured so the postmaster sees PGDATA2 every time it starts. Finally: $ initlocation PGDATA2 $ createdb -D PGDATA2 testdb Alternatively, if you allow absolute paths you could write: $ initlocation /opt/postgres/data $ createdb -D /opt/postgres/data/testdb testdb >From this I gather that what they *mean*, for the initlocation and createdb commands, is $PGDATA2. (Note the "$".) Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Prevent users from creating tables
"Campano, Troy" <[EMAIL PROTECTED]> wrote: > > Hello, > I'm trying to set up PostgreSQL for proof of concept according to our > standards. > I need to create a user for database01 that has the ability to create > any objects they want. > They can create tables, views, indexes, etc. > > Then I need a second user that has the privileges to only SELECT, > INSERT, UPDATE, DELETE from objects in a certain database. > > How do I grant these privs? > How do I prevent a user from dropping objects? http://www.postgresql.org/docs/7.4/static/sql-grant.html Jim ---(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: [GENERAL] perl access
Tom Allison <[EMAIL PROTECTED]> wrote:
>
> I'm stuck on something stupid.
>
> I'm trying to use perl to open up a database handle and I can't find the
> right database dsn string.
>
> my $data_source = "dbi:Pg:mydatabase";
> my $username = "mydatebasereader";
> my $auth = "secret";
>
> my $dbh = DBI->connect($data_source, $username, $auth);
>
>
>
> DBI connect('postfix','postfix',...) failed: missing "=" after "postfix"
> in connection info string at /home/tallison/bin/perl.pl line 21
>
> I've tried variations on the $data_source but I'm afraid I'm working on
> a hit-n-miss process.
>
> Can someone point me?
Like this:
my $data_source = "dbi:Pg:dbname=mydatabase";
^^^
Jim
---(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: [GENERAL] [HACKERS] Release 7.4.3 branded
Tom Lane <[EMAIL PROTECTED]> wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Release is scheduled for Monday. > > I'd like to remind people that the pre-release tarball is available from > the ftp servers under /pub/stable_snapshot ... I find nothing under pub/stable_snapshot. I do find stuff under pub/7.4.3. Is it released, then? >we had complaints last > time that people didn't have a chance to vet the release in advance, > and I don't want to hear that this time. Check it out... > [snip] > Speak now or hold your peace. I *tried* to get to it, to see if it would at least build on my various Sparc Solaris platforms. Perhaps I missed? Jim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Do we need more emphasis on backup?
Tom Lane <[EMAIL PROTECTED]> wrote: > [snip] > > We do need to point out that you're only as reliable as your last > backup. I'm not sure exactly where to say this. [snip] > Hmph. Backups are for mitigation against a catastrophic failure destroying or corrupting main storage. And even then: Subtle errors can induce data corruption that may go un-noticed until it's too late. (I.e.: The last correct backups have been over-written, retired, so old they've become unreadable, so old the data's no longer useful, etc.) My position is that your data is only as reliable as your hardware, period. Use cheap (usually PC, sorry) hardware and, well... I wonder how many people are aware of the fact that the cheaper PCs don't even have parity memory anymore? Then there are the issues with IDE drives. (Don't recall those, exactly - don't use 'em.) One of the other mailing lists I'm on: The project developer, whenever somebody comes on list and says "Your code is blowing up, losing stuff, corrupting stuff," or whatever, first asks "What hardware are you running?" IIRC, he gives short shrift to complainants running inexpensive PC hardware. He won't spend any time on the complaint until they prove it's *not* their hardware. Jim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Do we need more emphasis on backup?
Bruce Momjian <[EMAIL PROTECTED]> wrote: > > pgman wrote: > > Jim Seymour wrote: [snip] > > > > > > My position is that your data is only as reliable as your hardware, > > > period. [snip] > > > > There is a basic misconception that all PC hardware is created equal --- > > that hard drives, mother boards, and RAM are all the same because they > > are all PC-compatible. Compatible != Similar Quality. [snip] > > Should I add an FAQ discussing hardware selection and the importance of > reliable hardware? Scary to think that people who don't know enough about running a proper server, and thus have to be *told* this, are admin'ing databases. Start with: Gotta have ECC, or at least parity-checking, RAM. Mention the (some kinds of?) IDE drives issue. Mention that hardware RAID systems must have battery-backed write cache. (I actually had a RAID vendor, whose products no longer had batter-backed write cache, tell me "Just use a UPS.") Jim ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Do we need more emphasis on backup?
Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 06, 2004 at 08:32:15AM -0400, Jim Seymour wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > Should I add an FAQ discussing hardware selection and the importance of > > > reliable hardware? > > > > Scary to think that people who don't know enough about running a proper > > server, and thus have to be *told* this, are admin'ing databases. > [snip] > For us rest-of-the-worlders, it's not always possible to get top of the > line hardware. [snip] There's a difference between "not knowing your should" and "not being able to do it." I addressed cluelessness, not economic ability. > [snip] > > So I think it's a good idea to mention that better hardware can be > helpful. "Helpful?" Hmmm... You know, recently there was a "consumer alert" item during one of the major U.S. TV networks' news shows. It seems that all kinds of counterfeit products are making it into the stores here. Even after-market automotive brake pads made of nothing but compressed and painted/dyed vegetable matter. Needless to say, using brake bads made of proper brake pad material is "helpful." ;) Somebody's *ability* to employ proper hardware does not affect whether or not it's advisable to do so. This isn't a "rich" vs. "poor" issue. If you cannot do it, you cannot do it, and that's that. But that does not lessen the importance of knowing you should. > But don't make that sound like if you don't have it, it's the > end of the world or the admin is an uneducated moron. If your db destructs due to an undetected RAM problem (undetected because your computer has not even parity error detection) and the data in that db is "life or death" critical to your business, it might well be the end of the world as far as your business is concerned. Jim ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Do we need more emphasis on backup?
Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > New FAQ added: > > 3.11) What computer hardware should I use? > > Because PC hardware is mostly compatible, people tend to believe that > all PC hardware is of equal quality. It is not. ECC RAM, SCSI, and > quality motherboards are more reliable and have better performance than > less expensive hardware. PostgreSQL will run on almost any hardware, > but if you are building a server where reliability and performance are > concerns, it is wise to research your hardware options thoroughly. Our > email lists can be used to discuss hardware options and tradeoffs. > > Adjustments? Looks good to me. Succinct and non-judgemental. Well done! Oh, if you're accepting punctuation nits ;), in most cases, the comma should come after "but," not before it. So your sentence should read "PostgreSQL will run on almost any hardware but, if you are..." If you wanted to mention other issues to consider, you might include: > > ------- > > Jim Seymour wrote: > > [snip] > > > > Mention that hardware RAID systems must have battery-backed write > > cache. (I actually had a RAID vendor, whose products no longer had > > batter-backed write cache, tell me "Just use a UPS.") Also desirable are a quality UPS, with monitoring on the server for graceful shutdown of the server on battery exhaustion, and redundant power supplies. Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Do we need more emphasis on backup?
Doug McNaught <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Jim Seymour) writes: > > > Oh, if you're accepting punctuation nits ;), in most cases, the comma > > should come after "but," not before it. So your sentence should read > > "PostgreSQL will run on almost any hardware but, if you are..." > > Wrong. :) > > You are sentenced to go read Strunk and White again. I stand corrected. I always used to put the comma before "but," but changed after reading somewhere, or thinking I had, that was incorrect for certain sentence structures. Neither of my style guides supports what I said earlier, so I cannot imagine whence I got that idea. Jim ---(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: [GENERAL] installation: cc and gcc how to?
=?iso-8859-1?q?Nilabhra=20Banerjee?= <[EMAIL PROTECTED]> wrote: > > > Thanks a lot.. This much is enough for meIf I get > some time afterwards I go thru it again But I am > still curious to know about the CFlags variable..what > are the other values it can take. The pgsql tarball includes an INSTALL document. The INSTALL file, in turn, explains what the CFLAGS variable does. What's assigned to CFLAGS is dependent on a number of factors, such as operating system and version, compiler and version, hardware, etc., etc. Jim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Sql injection attacks
Bill Moran <[EMAIL PROTECTED]> wrote: > [snip] > > Simply put: > 1) If the untrusted value is a string, using a proper escape sequence should >make it safe. > 2) If the untrusted value is not a string, then it should be tested for >proper value (i.e. if it should be a number, it should be ensured that >it _is_ a number, and nothing else) invalid values should trigger an >error. > > I don't see how storing the SQL in some different location is the correct > way to fix anything? [snip] > I agree with Bill. Years ago (more years than I care to recall) I read a book on structured systems design (IIRC) that advised one should condition/convert data as early as possible in the process, throughout the design. Amongst the advantages cited for this tactic was that then you would know, everywhere else in the system, that you were dealing only with conditioned data. That practice, taken to heart relatively early in my career, has always stood me in good stead. Thus I recommend to others the same approach. In short: Any data coming from an untrusted source should always be de-fanged as early as possible. Jim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] no value fetch
Stephan Szabo <[EMAIL PROTECTED]> wrote: > > > On Tue, 27 Jul 2004, BRINER Cedric wrote: > > > hi, > > > > Imagine that I have the following table where ts_sent is a timestamp(0) > > > > select * from notification; > > to_used| ts_sent | from > > -+-+- > > [EMAIL PROTECTED] | 2004-07-21 14:19:43+02 | amanda > > [EMAIL PROTECTED] | | postgres > > > > and so, how do I do to fetch the second line by asking : > > catch me the line where ts_sent doesn't have a value ! > > > > I've try: > > select * from notification where ts_sent = null ; > > Use ts_sent IS NULL, not ts_sent = null. > > Pretty much, = null returns null. To expand on this... This is because NULL is nothing. Not zero, but *nothing*. Being nothing, it cannot "equal" anything. Not even itself. But a space can *contain* nothing. And it can contain "not nothing." Jim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] mirroring data on different drives?
Steve <[EMAIL PROTECTED]> wrote: > > Someone please please help me :-( [snip] Relax, Steve. The people helping-out on PostgreSQL mailing lists are in 24 timezones, have real jobs (for which they actually get paid), are all volunteers (for which they don't get paid), may be going to school, take vacations, sleep, etc. It may take some time, maybe hours, or even days, depending on a variety of factors, for somebody to address your question(s). And that's assuming somebody knows, has the time, and will take an interest. I'm no expert in pgsql performance, but I suspect you'd be better-off with UW-SCSI drives in a RAID array, than doing things like trying to put different bits on different drives. There are reams of other questions, such as: Do you "vacuum analyze" regularly? Do you have sufficient sort memory? It may be that your question(s) would be more appropriately directed to the performance mailing list, rather than general. You might also help yourself by spending some time searching/browsing the performance, admin and general mailing lists archives for past discussions of issues similar to yours. Jim ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] How to use as Functional Index to be used as Primary KEY
Janning Vygen <[EMAIL PROTECTED]> wrote: > [snip] > > Thanks to Tom and Peter for your answers. I will design my table without a > primary key and use my unique index instead of a primary key. As this unique > key is the same as a primary key i dont see the reason why postgresql > should't extend the specs and allow functional primary key indizes. Because, as Tom Lane wrote: "The SQL spec says that primary keys are columns or lists of columns." Unlike some other SQL RDBMs, PostgreSQL at least *tries* (mostly) to be SQL standards compliant. Jim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Where are all the users?
Kay-Uwe Genz <[EMAIL PROTECTED]> wrote: > > Hi @ all, > > I want to reference the User-ID PG use as an FOREIGN KEY in a tabel of > my DB. But I saw that pg_user is a view. Where are the information I > need? Maybe you could \d the view and find out? *But* you have to have the proper permissions to actually see/reference the data. Jim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
