[GENERAL] Re: Restore from a dead machine.
> Can't locate Pg.pm in @INC (@INC contains: /usr/libdata/perl/5.00503/mach > /usr/libdata/perl/5.00503 > /usr/local/lib/perl5/site_perl/5.005/i386-freebsd > /usr/local/lib/perl5/site_perl/5.005 .) at ./top25.pl line 2. > > Line 2 of the specific program reads:Use Pg; Make sure that the user running the script has read perms on the Pg.pm file. -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] Re: php Compile question
> This has been discussed quite a few times recently (in fact, I posted a > similar reply yesterday). From Tom Lane: > > "Change php_pgsql.h to refer to postgres_fe.h not postgres.h." ... or symlink postgres.h to postgres_fe.h ... -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Re: Logging Queries
> Is there any way to have the server log the queries that are coming in so I > can see what's actually getting processed? Start the postmaster with "-d 2" on the command line. -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] Re: Re: Fast Inserts and Hardware Questions
> [Interesting stats] > > > Wow, does WAL make so much of a difference as to make my > > two-generations-old, built-from-spare-parts scrap box faster than my > > latest and greatest production server? Yikes! > > What RAID level are you running? RAID-5 isn't always very > fast on writes. That and WAL might be what's up. Yes, it is RAID-5 on the big box. Unfortunately, I don't have any spare RAID equipped boxes sitting around, so I can't experiment with the different RAID levels. Still, you'd think that even a "slow" RAID-5 configuration would be faster than a $98 IDE drive... > Have you tried 7.1b5 on the big box? Not yet, I'm waiting for a quiet weekend. I'll post my stats when (if...) I get around to doing that. -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[GENERAL] error logging
I can't seem to find any docs that indicate what the different postmaster debug levels mean. I'm getting entries about syntax errors in my queries: ERROR: parser: parse error at or near "s" This alone is a pretty useless message and isn't going to help me find that one bad line of code. Is there a debug level that will only output the text of the queries if they fail? Level 1 doesn't give me any queries, and level 2 gives me all of them... -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] "critical mass" reached?
> Hm. As Richard remarks, 6M records is not an especially big table; > there are people running larger ones. The leftover sorttemp files sound > like you are suffering backend crashes --- but you didn't mention > anything about unexpected disconnects. I haven't noticed any myself, but the majority of our connections come from a public web based app -- so I can't really tell if the consumer is experiencing problems or not. > The postmaster log would be a good place to look for more info (if > you're not keeping one, turn it on). I have a debug level 2 log of almost the entire day's activity. I scanned it briefly but found nothing (it's 180 meg). Is there anything in particular I should be looking for? > Also, make sure the postmaster is not being run with an environment of > "ulimit -c 0" ... if the backends are crashing, we want to get some core > files so we can see what's happening. Ok, will verify. Thanks. -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] Re: "critical mass" reached?
> Presumably you're running vacuum analyze regularly (at least once a day I'd > guess) so I can only suspect that something has tipped the balance in the > cost estimations. Is there a particular query that's slow and can you post > an EXPLAIN? Oops, yes, sorry forgot to mention that. Vacuum analyze run nightly. There is not just one particluar query that runs slow -- it's the database as a whole (while apparently under the same average everyday load). > Looks like you've ruled out damage to the DB. What happens if you delete 3 > million of the records in your log-table? We haven't got that far yet. I was hoping to get some other ideas prior to doing something so drastic, but we'll try it ... > Six million _tables_ is a lot, but you're right 6M records is pretty small > compared to what some people are using. Oops again. I gotta stop trying to debug at 3am... :) -- Alex Howansky Wankwood Associates http://www.wankwood.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] how to determine what a process is doing
I've looked in the docs, Bruce's book, and the list archives, but I've been unable to find an answer to this. Any help would be greatly appreciated. I have a database front-ended by a web site. All queries (apart from a few cron jobs and developer's manual tests) come from the web site through PHP. Lately, my database server's load average has been spiking badly. There may be 50 concurrent queries running, and top shows that maybe three or four of them are really sucking up the horsepower. I'd like to find out what these hog processes are actually processing -- but it could be any one of a few hundred different queries. Is there any way to determine exactly what a postgres process is doing at any time? The output from the ps command only shows "INSERT" or "SELECT", and not the full query string. TIA, -- Alex Howansky Wankwood Associates http://www.wankwood.com/
