Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Fujii Masao <masao.fujii@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2010-04-23T20:11:38Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, I think the real hole is that turning archive_mode=on results in
> WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could have SR setups
that don't care about having a backing WAL archive.
> 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.
And when that limit is reached, what happens? Panic shutdown?
Silently drop unarchived data? Neither one sounds very good.
I think either you want your WAL archived or you don't. "Archive
if it's convenient" doesn't sound like a useful operating mode.
So maybe we do indeed need to keep archive_mode as a separate toggle.
regards, tom lane