On Fri, 2004-05-14 at 02:00, Tom Lane wrote:
> Michael Brusser <michael@synchronicity.com> writes:
> > It looks that "No such file or directory" followed by the abort signal
> > resulted from manually removing logs. pg_resetxlog took care of this,
> > but other problems persisted.
>
> > pg_dump: ERROR: XLogFlush: request 0/A971020 is not satisfied ---
> > flushed only to 0/5000050 ... lost synchronization with server, resetting
> > connection
>
> Okay, you have a page with an LSN of A971020 which is past end of XLOG
> (5000050). You may have created this problem for yourself by doing
> pg_resetxlog with poorly chosen parameters.
Michael,
>From reading this error logs, it would appear that this system has been
very strangely configured indeed.
The recommendations for usage are fairly clear
- don't use it on NFS....not cause we hate NFS....its just unsuited to
the task of serving files to a database system
- don't delete the transaction logs manually...they get recycled soon
enough anyhow
[ Is there a connection between the fact that it is on NFS and the logs
have been manually deleted? We know that SQLServer allows a "truncate
transcation log" facility....is that something that you were expecting
to see and trying to emulate with PostgreSQL? Were you trying to stop
NFS writes taking place?]
Your logs are rated very low. Is the transaction rate very low on this
system or has the system recently been set up? If it is the latter, then
its not too late to change.
Even if the transaction rate is low, what is the benefit of using NFS?
PostgreSQL offers client/server access - so why not use that instead?
Best Regards,
Simon Riggs