Обсуждение: 2019-02-14 Press Release Draft
Hi, Attached is a draft of the press release for the upcoming 2019-02-14 release. Feedback & suggestions are welcome. Thanks! Jonathan
Вложения
On 02/12/19 22:00, Jonathan S. Katz wrote: > Attached is a draft of the press release for the upcoming 2019-02-14 > release. Feedback & suggestions are welcome. ---- Users on PostgreSQL 9.4 should plan to upgrade to a supported version of PostgreSQL as the community will stop releasing fixes for it on February 12, 2019. Please see our [versioning policy](https://www.postgresql.org/support/versioning/) ---- Should that be February 13, 2020? That's what the linked page says for 9.4. February 12, 2019 would be (a) today, and (b) in the past for this press release. Cheers, -Chap
On 2/13/19 4:13 AM, Chapman Flack wrote: > On 02/12/19 22:00, Jonathan S. Katz wrote: >> Attached is a draft of the press release for the upcoming 2019-02-14 >> release. Feedback & suggestions are welcome. > > ---- > Users on PostgreSQL 9.4 should plan to upgrade to a supported version of > PostgreSQL as the community will stop releasing fixes for it on February 12, > 2019. Please see our [versioning > policy](https://www.postgresql.org/support/versioning/) > ---- > > Should that be February 13, 2020? That's what the linked page says for 9.4. > > February 12, 2019 would be (a) today, and (b) in the past for this press > release. Yes, good catch. Fixed. Thanks, Jonathan
Вложения
> On 13 Feb 2019, at 04:00, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Attached is a draft of the press release for the upcoming 2019-02-14
> release. Feedback & suggestions are welcome.
I think it should be “versions” in the below sentence?
"all currently supported version of PostgreSQL will only contain"
cheers ./daniel
> 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 uses thekernel 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 to diskby again calling `fsync()`, `fsync()` will report back that it succeeded, but the data that PostgreSQL believed to besaved 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? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
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
Вложения
Hi, On Tue, Feb 12, 2019 at 10:14:55PM -0500, Jonathan S. Katz wrote: > On 2/13/19 4:13 AM, Chapman Flack wrote: > > On 02/12/19 22:00, Jonathan S. Katz wrote: > >> Attached is a draft of the press release for the upcoming 2019-02-14 > >> release. Feedback & suggestions are welcome. > > > > ---- > > Users on PostgreSQL 9.4 should plan to upgrade to a supported version of > > PostgreSQL as the community will stop releasing fixes for it on February 12, > > 2019. Please see our [versioning > > policy](https://www.postgresql.org/support/versioning/) > > ---- > > > > Should that be February 13, 2020? That's what the linked page says for 9.4. > > > > February 12, 2019 would be (a) today, and (b) in the past for this press > > release. > > Yes, good catch. Fixed. Does it make sense to ring the alarm already, one year in advance? I haven't checked what we have been doing in the past, but now that we established the 9.4 EOL is well off, it might make those people weary that just managed to get rif off all their 9.3 instances last month... Michael
On 2/13/19 8:15 AM, Michael Banck wrote: > Hi, > > On Tue, Feb 12, 2019 at 10:14:55PM -0500, Jonathan S. Katz wrote: >> On 2/13/19 4:13 AM, Chapman Flack wrote: >>> On 02/12/19 22:00, Jonathan S. Katz wrote: >>>> Attached is a draft of the press release for the upcoming 2019-02-14 >>>> release. Feedback & suggestions are welcome. >>> >>> ---- >>> Users on PostgreSQL 9.4 should plan to upgrade to a supported version of >>> PostgreSQL as the community will stop releasing fixes for it on February 12, >>> 2019. Please see our [versioning >>> policy](https://www.postgresql.org/support/versioning/) >>> ---- >>> >>> Should that be February 13, 2020? That's what the linked page says for 9.4. >>> >>> February 12, 2019 would be (a) today, and (b) in the past for this press >>> release. >> >> Yes, good catch. Fixed. > > Does it make sense to ring the alarm already, one year in advance? I > haven't checked what we have been doing in the past, but now that we > established the 9.4 EOL is well off, it might make those people weary With the fixed end dates in place[1], the change in major version numbers, and having a few announcements leading up to the EOL were missed last year (IIRC we gave one warning), we wanted to provide more advanced warning about the next EOL of a version. That said, reading it without tired eyes, the language could come across as being alarmist, which is not the case. Maybe something like: ==snip== PostgreSQL 9.4 will stop receiving fixes on February 12, 2020. Please see our [versioning policy](https://www.postgresql.org/support/versioning/) for more information. ==snip== and subsequent releases can gradually increase the language. Thanks, Jonathan [1] https://www.postgresql.org/support/versioning/