Gavin Sherry <[EMAIL PROTECTED]> writes: > Interestingly, I *cannot* recreate on the single CPU system and I cannot > get abort() to generate a core.
By that do you mean that you don't see any corefile in the DB directory when you look after the dust settles? I ran into the same problem yesterday in another connection, and eventually realized that the corefile is getting removed because of the logic I added recently to do WAL replay of CREATE/DROP DATABASE. The regression test sequence is short enough (on modern machines) that there may not be any checkpoint between its start and the point where you have a crash, so that the initial "CREATE DATABASE regression" operation is still in the range of WAL entries to be replayed. In dbcommands.c it sez: /* * Our theory for replaying a CREATE is to forcibly drop the * target subdirectory if present, then re-copy the source data. * This may be more work than needed, but it is simple to * implement. */ So what's happening is that WAL replay is wiping the database directory (including the core file). I don't really want to change the CREATE DATABASE replay logic, so I was thinking of suggesting that we hack around this by modifying pg_regress to force a checkpoint right after its CREATE DATABASE. Then any crashes during the regression tests wouldn't cause a replay of the CREATE. This is mighty ugly though :-( regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])