"Yurgis Baykshtis" <ybaykshtis@micropat.com> writes:
> The most interesting thing is that rename failure is always followed by
> IpcMemoryCreate and vice-versa, IpcMemoryCreate always comes after the
> rename error.
That is not "interesting" ... it's exactly what I'd expect for the panic
recovery sequence (given that SHMMAX is preventing creation of a second
shared-memory segment).
>> What filesystem are you using, and what is the platform exactly?
> DBExperts 7.3.4 on Win2000 (so it's a cygwin-based system)
Perhaps you need to get a real operating system :-(. No such failure
mode has been reported on any Unix variant, AFAIR.
It's hard to be certain what's happening from the after-the-fact
evidence you've offered. I'd like to see what is in pg_xlog immediately
after the crash, *before* Postgres is restarted. I get the feeling that
what we will see is the destination filename already present and the
source not, which would suggest that two backends tried to do the rename
concurrently. AFAICS that must mean that the operating system's lock
support is broken, because we do not try to rename WAL segments except
while holding the CheckpointLock, not to mention the ControlFileLock.
This is not necessarily Windows' fault, it could be a cygwin or cygipc
bug ... are you up to date on those?
regards, tom lane
