anypossibility wrote:
> I am running postgres and data directory is on network volume.
Unless you are using a SAN *and* really know what you're doing,
that's not generally a good idea.
> When postgres try to recover from the crash it has no access to
> storage.
If it couldn't reach any part of the data directory, including
pg_xlog, that makes no difference. Of course, this is a really good
point in time (before trying to start PostgreSQL) to make a backup of
your data directory, to be kept for at least several weeks.
> Once storage volume is re-connected:
> There were index corruptions
> Also some missing data... All records seems to be updated
> before/after Last know up (9:30).
OK, if you didn't make that backup before, these events should be
taken as not-very-subtle indications that a backup is crucial.
> I understand that some updates were in cache and haven't been
> written to the disk yet hence updates are lost.
As long as things are configured such that an fsync doesn't return
until the data is persisted, you will have all data which was written
in a transaction which was successfully committed. (As long as you
didn't turn fsync or full_page_writes off, that is.)
> However, it seems that record that were created long time ago (but
> updated before the crash occurs) is completely missing (unable to
> find even after reindex is done).
> Does this make sense? or Is this impossible and record might be
> somewhere on the disk?
It's not totally impossible that something could yet be recovered,
but you haven't given us nearly enough information to know that.
(Error messages and any relevant log entries would be helpful.)
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Misdirected recovery attempts can destroy data in a corrupted
database; a backup before attempts is *really* important.
-Kevin