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