Re: recovery_connections cannot start (was Re: master in standby mode croaks)

On Fri, Apr 23, 2010 at 3:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ...  I'm still unconvinced of our ability to come
>> up with a solid design in the time we have, but I think it would make
>> sense to listen to proposals people want to make.  I poked some holes
>> in Heikki's design from this morning (which was, more or less, my
>> design from last week) but that doesn't mean they can't be plugged.
>
> The only hole I saw poked was the one about how archive_mode is used to
> decide whether to start the archiver process.  I think we could
> reasonably deal with that by starting the archiver iff wal_mode > 'crash'.
> There's no point in archiving otherwise, and the overhead of an idle
> archiver is small enough that we can live with the corner cases where
> you're starting an archiver you don't really need.

Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.

But we might be able to handle that like this:

wal_mode={standby|archive|crash} # or whatever
wal_segments_always=<integer> # keep this many segments always, for
SR - like current wal_keep_segments
wal_segments_unarchived=<integer> # keep this many unarchived
segments, -1 for infinite
max_wal_senders=<integer> # same as now
archive_command=<string> # same as now

So we always retain wal_segments_always segments, but if we have
trouble with archiving we'll retain up to wal_segments_archived.

...Robert