Re: recovery_connections cannot start (was Re: master in standby mode croaks)
От | Tom Lane |
---|---|
Тема | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Дата | |
Msg-id | 15689.1272053498@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: recovery_connections cannot start (was Re: master in standby mode croaks) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: recovery_connections cannot start (was Re: master in
standby mode croaks)
|
Список | 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
В списке pgsql-hackers по дате отправления: