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 n
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, and
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'),
(NEW.user_
On Fri, Feb 20, 2009 at 10:45 PM, Uwe C. Schroeder 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?
>>
>> -
On Sat, Feb 21, 2009 at 1:43 AM, Michael Monnerie
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
> really have shutdown itself afte
On Sat, Feb 21, 2009 at 1:23 AM, Michael Monnerie
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 time. Is there a
> smart way to do suc
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
tsa...
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 boun
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 bro
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
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 (pgsql-ad
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 failure
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 a
On Sat, Feb 21, 2009 at 3:11 AM, Tena Sakai 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, checkpoint_segments is
>
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
J
On Sat, Feb 21, 2009 at 3:41 PM, Ron Mayer
wrote:
> 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'
>
16 matches
Mail list logo