Re: does wal archiving block the current client connection?

Jeff Frost <jeff(at)frostconsultingllc(dot)com> 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