RE: Disable WAL logging to speed up data loading

Поиск
Список
Период
Сортировка
От osumi.takamichi@fujitsu.com
Тема RE: Disable WAL logging to speed up data loading
Дата
Msg-id OSBPR01MB48885361D758639102DCED7BED170@OSBPR01MB4888.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Disable WAL logging to speed up data loading  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Disable WAL logging to speed up data loading  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
Hi, Laurenz


> > I wrote and attached the first patch to disable WAL logging.
> > This patch passes the regression test of check-world already and is
> > formatted by pgindent.
> 
> Without reading the code, I have my doubts about that feature.
> 
> While it clearly will improve performance, it opens the door to data loss.
Therefore, this feature must avoid that
that kind of inconsistent server starts up again.
This has been discussed in this thread already.

> People will use it to speed up their data loads and then be unhappy if they
> cannot use their backups to recover from a problem.
> 
> What happens if you try to do archive recovery across a time where wal_level
> was "none"?  Will the recovery process fail, as it should, or will you end up
> with data corruption?
> 
> We already have a performance-related footgun in the shape of fsync = off.
> Do we want to add another one?
Further, in this thread, we discuss that 
this feature is intended to serve under
some specific opportunities like DBA wants
to load data as soon as possible and/or the operation itself is easily *repeatable*.
So, before and after the change of wal_level, DBA needs to take a full backup to
prepare the unexpected crash.

But anyway, I'll fix and enrich the documents. Thanks.

Best,
    Takamichi Osumi

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

Предыдущее
От: Oleksandr Shulgin
Дата:
Сообщение: Re: cutting down the TODO list thread
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: shared tempfile was not removed on statement_timeout