Pgsql taking a *lot* of CPU time (unkillable).

Hello,

I'm currently running PostgreSQL 7.4.6 under NetBSD 2.0 (Release), but
with a custom kernel. I can start it, and it performs normally, i.e. I
can access my databases and such. Now I'm primarily using it with the
GNUCash PostgreSQL backend.

After I've finished using it, and leaving it to itself for a while, it
starts to consume all CPU time for, apparently, no good reason
(because it's not doing anything).

I started it thusly:
/usr/pkg/bin/postmaster -i -D /usr/pkg/pgsql/data/

And the following output appeared:

LOG: database system was interrupted at 2005-01-14 13:52:42 CET
LOG: checkpoint record is at 0/2329AA0
LOG: redo record is at 0/2329AA0; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 46264; next OID: 142900
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/2329AE0
LOG: redo is not required
LOG: database system is ready

ps auxww | grep pgsql shows:
pgsql 15786 94.8 0.3 4380 568 p2 R+ 4:13PM 5:13.13
/usr/pkg/bin/postmaster -i -D /usr/pkg/pgsql/data/ (postgres)
pgsql 24309 0.0 0.0 5368 4 p2 IW+ 4:13PM 0:00.01
postmaster: stats buffer process (postgres)
pgsql 25177 0.0 0.0 4420 4 p2 IW+ 4:13PM 0:00.01
postmaster: stats collector process (postgres)
pgsql 29008 0.0 0.0 0 0 p2 ZW+ - 0:00.00 (postgres)

Top gives:
15786 pgsql 64 0 4380K 568K RUN 5:56 93.80% 93.80% postgres

Now, the program won't respond to kill, or to a ctrl+c on the command
line, I have to kill it with -9.

I've tried to run it with a higher debug level, but this does not give
any useful information, except for a sequence of (of course, while
performing query's with gnucash, a lot of query information is shown,
but after quitting it and leaving postmaster to itself only this is
shown):

DEBUG: proc_exit(0)
DEBUG: shmem_exit(0)
DEBUG: exit(0)
DEBUG: child process (PID 24738) exited with exit code 0

With varying PID's. After a while, this stops, and everything hangs as
described above. The only thing to remark is that it does not seem to
happen when running with -d 5 (but I'm not really sure).

As said, I'm running NetBSD 2.0, with my own kernel, on the i386
platform. I hope this gives someone enough information to make a guess
about the cause, although I realise the problem is quite vague.

Berteun