"Thomas H." <me@alternize.com> writes:
> it is defenitely the writer process that blocks the db. but in every case
> the writer process seems to fail to rename the file due to another
> postgresql still holding a filehandle to the very xlog file that should be
> renamed.
Right, all you need is a backend process that's made at least one xlog
write and then is left to sit idle for long enough that that xlog file
is due for recycling.
However, the fact that the writer process is stuck should not in itself
cause the DB to lock up. I think what's really happening is that after
the writer process gets stuck, the remaining backends chew all the
available WAL, and then they need to create more WAL segments for
themselves, and the writer process is holding the ControlFileLock so
they can't.
It might be interesting to think about not requiring the ControlFileLock
to be held while making new WAL segments. I think the only reason it
does that is to ensure that link/rename failure can be treated as a hard
error (because no one could have beat us to the filename), but we're
already having to back off that stance for Windows ...
regards, tom lane
