Thank you Andrew for your reply. I see, As there are many reasons exists for the data corruption i couldn't figure out it exactly. Unfortunately there is no backup for this system and is not possible to restore from the backup.
I have been using the NFS storage since 2013 and didn't experience this issue before, now i am afraid. We haven't set to run the fysnc() in our environment. If i set "fysnc to on" now, did it make any impact to current flow? Also i will considering the suggestion to upgrade the PostgreSQL. Regards, Prajilal On Thu, Mar 19, 2015 at 7:39 PM, Andrew Sullivan <a...@crankycanuck.ca> wrote: > On Thu, Mar 19, 2015 at 07:02:28PM +0900, Prajilal KP wrote: > > > > When i see check the this file, the file itself exists but the size is > "0" > > byte. > > That suggests you have data corruption, and that you need to restore from > backup. > > > The server is writing the whole log in to the mounted network storage, > NFS. > > There are reasons that people get nervous about databases on NFS. Are > you ensuring that Postgres fsync() calls (like when COMMIT happens) > are not being handled asynchronously? > > Also, a trivial scan of the release notes in the 9.0.x series shows a > number of data corruption fixes since 9.0.4. You should always try to > stay on the latest minor release of your version of Postgres. > > Best regards, > > A > > -- > Andrew Sullivan > a...@crankycanuck.ca > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
