Обсуждение: PostgreSQL Database freezes during backup then generates drwtsn.exe process
I’m running PostgreSQL 8.3 on a Windows 2003 machine (pgAgent service is also installed and running). The system is running as a redundant database server. Thus, backing up from one machine to another, and transferring over WAL logs. In the postageSQL log files there are several error messages that read:
‘could not rename file, no such file or directory’
Eventually, postgreSQL ‘freezes’, I’m unable to access the database, and there is no logging. I find a drwtsn.exe process running under the postgres account in Task Manager. If I kill the drwtsn PostgreSQL service will stop. I can then restart it and the database will run as expected for a few days.
Has anyone encountered this problem before? If so, were you able to find a solution?
Thanks for any help in advance.
Ward Eaton
Project Engineer Automation
RAD-CON Inc.
TECHNOLOGY: Innovative & Proven
Office: +1.216.706.8927
Fax: +1.216.221.1135
Website: www.RAD-CON.com
E-mail: Ward.Eaton@RAD-CON.com
Вложения
| Ward, I've experienced the exact problem you describe. The two machines where identical in every way: make, model, disk layout, OS, etc., and this scenario happens regardless of which machine was the primary and which was the warm-standby. Note I was not running pgAgent. I was using pg_standby to implement copying of WAL files between machines. It would copy the WAL file to a network shared directory, where the warm-standby would pick up the file and use it, until the fatal error you describe happened. I had discovered that during a copy operation Windows will allocate the entire file size on the target prior to completing the file copy. This differs from Unix, and may have something to do with the errors we are seeing. I'm speculating here, but I believe when the recovery code "sees" a 16 Mb file it thinks the entire file contents are available, which is not necessarily the case with Windows. I know some folks recommend rsync, but that requires installing cygwin and my client isn't happy with that idea. Possibly copying the WAL file to a temporary location, then moving it to the target location may mitigate the problem, since move operations (on the same disk drive, anyway) in Windows simpy rejigger the file descriptor and don't reallocate any disk space. I haven't tried it yet, but I'm moving in that direction. Regards, Bob Lunney --- On Tue, 12/2/08, Ward Eaton <Ward.Eaton@rad-con.com> wrote: From: Ward Eaton <Ward.Eaton@rad-con.com> |
