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 <ajs@xxxxxxxxxxxxxxx> 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
ajs@xxxxxxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
