On Fri, Apr 23, 2010 at 3:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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
