Re: 2019-02-14 Press Release Draft

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: 2019-02-14 Press Release Draft
Дата
Msg-id e485cdc0-aa8d-a1a0-1378-62b95f28c1ad@postgresql.org
обсуждение исходный текст
Ответ на Re: 2019-02-14 Press Release Draft,2019-02-14 Press Release Draft  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список pgsql-hackers
On 2/13/19 1:35 PM, Tatsuo Ishii wrote:
>> 2019-02-14 Cumulative Update Release
>> ====================================
>>
>> The PostgreSQL Global Development Group has released an update to all supported versions of our database system,
including11.2, 10.7, 9.6.12, 9.5.16, and 9.4.21. This release changes the behavior in how PostgreSQL interfaces with
`fsync()`and includes fixes for partitioning and over 70 other bugs that were reported over the past three months. 
>>
>> Users should plan to apply this update at the next scheduled downtime.
>>
>> Highlight: Change in behavior with `fsync()`
>> ------------------------------------------
>>
>> When available in an operating system and enabled in the configuration file (which it is by default), PostgreSQL
usesthe kernel function `fsync()` to help ensure that data is written to a disk. In some operating systems that provide
`fsync()`,when the kernel is unable to write out the data, it returns a failure and flushes the data that was supposed
tobe written from its data buffers. 
>>
>> This flushing operation has an unfortunate side-effect for PostgreSQL: if PostgreSQL tries again to write the data
todisk by again calling `fsync()`, `fsync()` will report back that it succeeded, but the data that PostgreSQL believed
tobe saved to the disk would not actually be written. This presents a possible data corruption scenario. 
>>
>> This update modifies how PostgreSQL handles a `fsync()` failure: PostgreSQL will no longer retry calling `fsync()`
butinstead will panic. In this case, PostgreSQL can then replay the data from the write-ahead log (WAL) to help ensure
thedata is written. While this may appear to be a suboptimal solution, there are presently few alternatives and, based
onreports, the problem case occurs extremely rarely. 
>
> Shouldn't we mention that previous behavior (retrying fsync) can be
> chosen by a new GUC parameter?

Ah, I had that in my original copy and accidentally took it out. I have
added it back in, basically taking the exact language from the release
notes.

Per that and other feedback, I have attached v2.

Thanks so much for your quick responses.

Jonathan

Вложения

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

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: 2019-02-14 Press Release Draft,2019-02-14 Press Release Draft
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: Libpq support to connect to standby server as priority