Re: [ADMIN] 8.3.5 broken after power fail

2009-02-21 Thread Michael Monnerie
On Mittwoch 18 Februar 2009 Scott Marlowe wrote: Look into zero damaged pages setting. Thanks for the hint Scott, I tried it and did: select * into mb from dbmail_messageblks; WARNING: invalid page header in block 973075 of relation pg_toast_1281127; zeroing out page ERROR: missing chunk

Re: [ADMIN] 8.3.5 broken after power fail SOLVED

2009-02-21 Thread Michael Monnerie
I managed to recover the data that was still readable. About 650 messageblock entries got lost. What makes me nervous a bit is that postgres kept running despite (partially) being destroyed. It should really have shutdown itself after the first problem was found. That database is for mails,

[ADMIN] Question on rule

2009-02-21 Thread Michael Monnerie
I have a question to creating a rule: CREATE RULE dbmail_mailboxes_autocreate AS ON INSERT TO dbmail_users DO ALSO insert into dbmail_mailboxes (owner_idnr,name) values (NEW.user_idnr,'INBOX'), (NEW.user_idnr,'Gesendete Objekte'), (NEW.user_idnr,'Entwürfe'), (NEW.user_idnr,'Junk'),

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Scott Marlowe
On Fri, Feb 20, 2009 at 10:45 PM, Uwe C. Schroeder u...@oss4u.com wrote: On Friday 20 February 2009, Tena Sakai wrote: Hi Scott, What does explain and (it'll take a while to get it) explain analyze select ... have to say?

Re: [ADMIN] 8.3.5 broken after power fail SOLVED

2009-02-21 Thread Scott Marlowe
On Sat, Feb 21, 2009 at 1:43 AM, Michael Monnerie michael.monne...@is.it-management.at wrote: I managed to recover the data that was still readable. About 650 messageblock entries got lost. What makes me nervous a bit is that postgres kept running despite (partially) being destroyed. It should

Re: [ADMIN] 8.3.5 broken after power fail

2009-02-21 Thread Scott Marlowe
On Sat, Feb 21, 2009 at 1:23 AM, Michael Monnerie michael.monne...@is.it-management.at wrote: Also a question: Because I must read all data, the psql client runs out of memory, trying to cache all the 10GB from that table. I circumvented this with selecting only parts of the table all the

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Tena Sakai
Hi Uwe, I can certainly add indices and run analyze on each table and look at the performance. I am going to upgrade to 8.3.6 (I am at 8.3.3) and then add indices. It might take a few days before I can update you with outcome, but I will keep you posted. Many thanks. Regards, Tena Sakai

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Tena Sakai
Hi Scott, Thanks for clustering suggestion. I have never used cluster command and I need to read up before I can use it. I have adjusted postgres parameters per your recommen- dation. Work_mem is now 8GB, checkpoint_segments is raised to 100. Shared_buffers is still at 1GB because this is

Re: [ADMIN] 8.3.5 broken after power fail

2009-02-21 Thread Michael Monnerie
On Samstag 21 Februar 2009 Scott Marlowe wrote: You can dump individual tables with pg_dump -t table1 -t table2.  That should work without running out of memory.  And yeah, temp tables and select into are a good way to get your data ready to be pg_dumped. Yes, actually I did pg_dump -T

Re: [ADMIN] 8.3.5 broken after power fail SOLVED

2009-02-21 Thread Michael Monnerie
On Samstag 21 Februar 2009 Scott Marlowe wrote: We preach this again and again.  PostgreSQL can only survive a power outage type failure ONLY if the hardware / OS / filesystem don't lie about fsync.  If they do, all bets are off, and this kind of failure means you should really failover to

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Jan-Peter Seifert
Hello, I have adjusted postgres parameters per your recommen- dation. Work_mem is now 8GB, GB is just a typo I guess? Otherwise the value is insanely high. See: http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html Peter -- Sent via pgsql-admin mailing list

Re: [ADMIN] 8.3.5 broken after power fail SOLVED

2009-02-21 Thread Naomi Walker
Other than disaster tests, how would I know if I have an system that lies about fsync? We preach this again and again. PostgreSQL can only survive a power outage type failure ONLY if the hardware / OS / filesystem don't lie about fsync. If they do, all bets are off, and this kind of

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Tena Sakai
Hi Peter, GB is just a typo I guess? No, it isn't a typo. I meant it. Otherwise the value is insanely high. I kinda agree, but I am in a process of finding an equilibrium for my application. (I must admit I am doing so in a bit of blind fashion, but that's kinda where I am at.) As I look at

Re: [ADMIN] very, very slow performance

2009-02-21 Thread Scott Marlowe
On Sat, Feb 21, 2009 at 3:11 AM, Tena Sakai tsa...@gallo.ucsf.edu wrote: Hi Scott, Thanks for clustering suggestion. I have never used cluster command and I need to read up before I can use it. I have adjusted postgres parameters per your recommen- dation. Work_mem is now 8GB,

Re: [ADMIN] 8.3.5 broken after power fail SOLVED

2009-02-21 Thread Ron Mayer
Naomi Walker wrote: Other than disaster tests, how would I know if I have an system that lies about fsync? Well, the linux kernel tries to detect it on bootup and will give messages like this: %dmesg | grep 'disabling barriers' JBD: barrier-based sync failed on md1 - disabling barriers