Re: Problem while setting the fpw with SIGHUP

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Problem while setting the fpw with SIGHUP
Дата
Msg-id 20180413012952.GC1552@paquier.xyz
обсуждение исходный текст
Ответ на Re: Problem while setting the fpw with SIGHUP  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Problem while setting the fpw with SIGHUP  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Problem while setting the fpw with SIGHUP  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
> I think it may actually be confusing.  If you run pg_ctl reload and it
> reports that the value has changed, you'll expect it to have taken
> effect.  But really, it will take effect at some later time.

It is true that sometimes some people like to temporarily disable
full_page_writes particularly when doing some bulk load of data to
minimize the effort on WAL, and then re-enable it just after doing
the inserting this data.

Still does it matter when the change is effective?  By disabling
full_page_writes even temporarily, you accept the fact that this
instance would not be safe until the next checkpoint completes.  The
instance even finishes by writing less unnecessary WAL data if the
change is only effective at the next checkpoint.  Well, it is true that
this increases potential torn pages problems but the user is already
accepting that risk if a crash happens until the next checkpoint then it
exposes itself to torn pages anyway as it chose to disable
full_page_writes.
--
Michael

Вложения

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Instability in partition_prune test?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning