I wrote: > > Other times, I get the more ominous > DEBUG: rename from C:\postgres\peer_direct\data/pg_xlog/0000000000000003 > to C:\postgres\peer_direct\data/pg_xlog/000000000000000A (initialization > of log file 0, segment 10) failed: Permission denied. > > If this happens about 10 times I will have about 7 backends up with 6 > doing nothing and only 44k memory allocated for each. Killing the > client app kills all the backends.
OK, I read the readme file and saw the note about the permission denied error, so I'm not crazy. However, there was no mention of the extra processes which seems to me to be a catastrophic side affect. The processes appear to be waiting on some sort of lock on the transaction files, and seem to be in some sort of limbo until the original connection is closed. I can create very reasonable conditions which will take a database down within a few hours. Has this been fixed? If not, I'm prepared to start slogging it out. The way I see it, a production database is 100% likely to shut down within a very short period of time (hours) unless special care is taken to reset all the database connections or at least TerminateProcess() dormant processes (yuck!). I know the peerdirect patches are being applied to the cvs version. Aside from this problem and the very silly divide by zero error, the win32 port has been very well behaved, with decent, if not great, performance. Merlin ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
