Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> writes: > Well now, will you look at this: > postgres 20228 1 0 May17 ? 00:00:00 postgres: archiver process > postgres 20573 1 0 May17 ? 00:00:00 postgres: archiver process > postgres 23817 23810 0 May17 pts/11 00:00:00 postgres: archiver process > 23810 is the running postmaster: > postgres 23810 1 0 May17 pts/11 00:03:01 /usr/local/pgsql-8.1.3/bin/postm Well, there's our smoking gun. IIRC, all the failures you showed us are consistent with race conditions caused by multiple archiver processes all trying to do the same tasks concurrently. Do you frequently stop and restart the postmaster? Because I don't see how you could get into this state without having done so. I've just been looking at the code, and the archiver does commit hara-kiri when it notices its parent postmaster is dead; but it only checks that in the outer loop. Given sufficiently long delays in the archive_command, that could be a long time after the postmaster died; and in the meantime, successive executions of the archive_command could be conflicting with those launched by a later archiver incarnation. Seems we need an interlock to ensure there's not more than one archiver active. regards, tom lane
