Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog
Дата
Msg-id CABUevEy9WLCiNUexMBYXc6yr65dXLcetn=fzc4yoYOm26D2dsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers


On Fri, Feb 24, 2017 at 3:52 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Fri, Feb 24, 2017 at 1:10 AM, Magnus Hagander <magnus@hagander.net> wrote:
> I'm not sure this logic belongs in pg_receivexlog. If we put the decision
> making there, then we lock ourselves into one "type of policy".
>
> Wouldn't this one, along with some other scenarios, be better provided by
> the "run command at end of segment" function that we've talked about before?
> And then that external command could implement whatever aging logic would be
> appropriate for the environment?

OK, I forgot a bit about this past discussion. So let's say that we
have a command, why not also allow users to use at will a marker %f to
indicate the file name just completed? One use case here is to scan
the file for the oldest and/or newest timestamps of the segment just
finished to do some retention policy with something else in charge of
the cleanup.

The option name would be --end-segment-command? Any better ideas of names?

Oh, I definitely think such a command should be able to take a placeholder like %f telling which segment it has just processed. In fact, I'd consider it one of the most important features of it :) 

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Proposal for changes to recovery.conf API