Re: AdvanceXLInsertBuffer vs. WAL segment compressibility

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Дата
Msg-id CAA4eK1L7UvOS8TpUvoMuGZ4Mid=Mef-Cq5Q0M-2oYSHC-CSikw@mail.gmail.com
обсуждение исходный текст
Ответ на AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
On Sat, Jul 23, 2016 at 3:32 AM, Chapman Flack <chap@anastigmatix.net> wrote:
>
> Would it then be possible to go back to the old behavior (or make
> it selectable) of not overwriting the full 16 MB every time?
>

I don't see going back to old behaviour is an improvement, because as
as you pointed out above that it helps to improve the compression
ratio of WAL files for tools like gzip and it doesn't seem advisable
to loose that capability.  I think providing an option to select that
behaviour could be one choice, but use case seems narrow to me
considering there are tools (pglesslog) to clear the tail.  Do you
find any problems with that tool which makes you think that it is not
reliable?

> Or did the 9.4 changes also change enough other logic that stuff
> would now break if that isn't done?
>

The changes related to the same seems to be isolated (mainly in
CopyXLogRecordToWAL()) and doesn't look to impact other parts of
system, although some more analysis is needed to confirm the same, but
I think the point to make it optional doesn't seem convincing to me.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: bug in citext's upgrade script for parallel aggregates
Следующее
От: Thomas Munro
Дата:
Сообщение: LWLocks in DSM memory