Robert,
> I don't really see how that's any different from what happens now. If
> (for whatever reason) the master is generating WAL faster than a
> streaming standby can replay it, then the excess WAL is going to pile
> up someplace, and you might run out of disk space. Time-delaying the
> standby creates an additional way for that to happen, but I don't
> think it's an entirely new problem.
Not remotely new. xlog partition full is currently 75% of the emergency
support calls PGX gets from clients on 9.0 (if only they'd pay attention
to their nagios alerts!)
> I am not sure exactly how walreceiver handles it if the disk is full.
> I assume it craps out and eventually retries, so probably what will
> happen is that, after the standby's pg_xlog directory fills up,
> walreceiver will sit there and error out until replay advances enough
> to remove a WAL file and thus permit some more data to be streamed.
Nope, it gets stuck and stops there. Replay doesn't advance unless you
can somehow clear out some space manually; if the disk is full, the disk
is full, and PostgreSQL doesn't remove WAL files without being able to
write files first.
Manual (or scripted) intervention is always necessary if you reach disk
100% full.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
