> >Thanks Shaun! > >Yes, we're getting synchronous_commit on right now. > >The log_min_duration was briefly set to 0 at the time I sent out the post, >just to see what statements were logged right before everything went to >hell. Didn't yield much since we very quickly realized we couldn't cope >with the volume of logs. > >We also noticed that when trying to recover from a snapshot and replay >archived wal logs, it would corrupt right away, in under an hour. When >recovering from snapshots *without* replaying wal logs, we go on for a day >or two without the problem, so it does seem like wal logs are probably not >being flushed to disk as expected. > >Will update once we get onto the new h/w to see if that fixes it. >>> FYI - the change of server hardware didn't help >>> Also, I'm able to run a full pg_dump of the database (without output >>>to /dev/null) and it completes okay. >>> And then a few hours later the issue shows up again >>> We run an ext3 filesystem with journaling=ordered, and kernel 2.6.18 >>> Currently testing an upgrade to the kernel and turning off journaling >>>on the filesystem to see if that will help > >Thanks, >Karthik > > > >-- >Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
