Re: Need Force flag for pg_drop_replication_slot()

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Need Force flag for pg_drop_replication_slot()
Дата
Msg-id 20150529203139.GQ26667@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Need Force flag for pg_drop_replication_slot()  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
* Josh Berkus (josh@agliodbs.com) wrote:
> On 05/29/2015 11:30 AM, Stephen Frost wrote:
> > I know how big my WAL partition is.  Let me tell PG how big it is and to
> > not do anything that'll end up going over that amount, and we'll never
> > see a crash due to out of disk space for WAL again.
>
> Hmmmm.  Do we have a clear idea anywhere in server memory how many WAL
> segments there are?

Why does it need to be in shared memory..?

Clearly, when we're looking at cleaning up the WAL files, we know if the
archive command is failing and what file we're trying to archive, or if
we're not able to recycle a given file because we have logical
replication slots that want it, etc.

We certainly know where we're currently at in the WAL stream and we know
how big each WAL file is..

We just need a knob to be able to say "alright, this WAL file might
still be desired by something, but we're running out of room for *new*
WAL and, therefore, that's just too bad for those process that want it"
and recycle it anyway.  There are probably error conditions we have to
consider for replication slots when that happens, etc, but I don't think
we lack the info to make the decision, except for what value to set the
knob to, which is clearly system-dependent.
Thanks!
    Stephen

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [CORE] postpone next week's release
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [CORE] postpone next week's release