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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: recovery_connections cannot start (was Re: master in standby mode croaks)