I have been testing the postgresql Peer Direct port. I've used both the
released binary and my own compiled version and get the same behavior.
Please not that this is for testing purposes and I am not asking for
support.
I'm running an import routine which moves records from a cobol database
to postgres. This is strictly an import routine, where all queries are
serialized. The postgres.conf file is set to defaults, except for
fsync=false and the change in the WAL setting (see below). All sql
statements are made using the libpq interface, and are simply create
table followed by create index... followed by insert (repeat). Table
sizes range from 0 to about 300k records, and there about 100 tables.
Most of the tables have at least 10 fields, and all of the tables have
at least one index, usually several. The client and the server are
running on the same machine. There is no other activity on the
database, and the import does not use transactions of any kind.
About once in every 3000-5000 inserts, a new backend gets created
without the previous one getting shut down. About 75% of the way though
the process, too many backends get created and the import fails. The
first time through, postmaster is reporting things like:
DEBUG: Removing transaction log file 000000000000000000
DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES
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.
The second time through I tried increasing the WAL files from 0 to
eight. This did remove the XLogWrite: messages but did not fix the
problem. There is not much point in turning fsync on because this would
take too long. I could get the data in very easily with a preformatted
copy, but I thought I'd pass this information along!
Merlin
