Thread: 2021-08-12 release announcement draft
Hi, Attached is a draft for the 2021-08-12 release announcement. Please review for technical accuracy. Please ensure you have your feedback in no later than midnight today (Aug 11) AoE[1]. Thanks! Jonathan [1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
Attachment
On Wed, Aug 11, 2021 at 9:32 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: > Please ensure you have your feedback in no later than midnight today > (Aug 11) AoE[1]. I think that the pg_upgrade item should say that we now avoid forcing an anti-wraparound VACUUM on upgrade. This was never necessary. -- Peter Geoghegan
On 8/11/21 1:35 PM, Peter Geoghegan wrote: > On Wed, Aug 11, 2021 at 9:32 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: >> Please ensure you have your feedback in no later than midnight today >> (Aug 11) AoE[1]. > > I think that the pg_upgrade item should say that we now avoid forcing > an anti-wraparound VACUUM on upgrade. This was never necessary. How about: * `pg_upgrade` now carries forward the old installation's `oldestXID` value, which can improve things from a performance standpoint by no longer forcing an anti-wraparound `VACUUM`. ? Jonathan
Attachment
On Wed, Aug 11, 2021 at 11:23 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: > How about: > > * `pg_upgrade` now carries forward the old installation's `oldestXID` > value, which can improve things from a performance standpoint by no > longer forcing an anti-wraparound `VACUUM`. I don't think that framing this as a performance thing really makes sense. It certainly helps performance to not do something that's totally unnecessary, and only ever happened because of a bug in the implementation. But to me the point is that we're not doing these weird wholly unnecessary antiwraparound VACUUMs on upgrade now. Running pg_upgrade no longer affects when or how we VACUUM, which is exactly what you'd expect all along. -- Peter Geoghegan
On 8/11/21 2:29 PM, Peter Geoghegan wrote: > On Wed, Aug 11, 2021 at 11:23 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: >> How about: >> >> * `pg_upgrade` now carries forward the old installation's `oldestXID` >> value, which can improve things from a performance standpoint by no >> longer forcing an anti-wraparound `VACUUM`. > > I don't think that framing this as a performance thing really makes > sense. I had grabbed the performance bit from the release notes (though the comment was "[t]hat's not desirable from a performance standpoint."). It certainly helps performance to not do something that's > totally unnecessary, and only ever happened because of a bug in the > implementation. But to me the point is that we're not doing these > weird wholly unnecessary antiwraparound VACUUMs on upgrade now. > Running pg_upgrade no longer affects when or how we VACUUM, which is > exactly what you'd expect all along. So perhaps: "* `pg_upgrade` now carries forward the old installation's `oldestXID` value and no longer forces an anti-wraparound `VACUUM`." or maybe even: "* `pg_upgrade` no longer forces an anti-wraparound `VACUUM`." Jonathan
Attachment
On Wed, Aug 11, 2021 at 11:42 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: > So perhaps: > > "* `pg_upgrade` now carries forward the old installation's `oldestXID` > value and no longer forces an anti-wraparound `VACUUM`." > > or maybe even: > > "* `pg_upgrade` no longer forces an anti-wraparound `VACUUM`." I prefer the first one, fwiw. -- Peter Geoghegan
On Wed, Aug 11, 2021 at 12:32:41PM -0400, Jonathan S. Katz wrote: > * walsenders now show their latest replication commands in `pg_stat_activity`, > instead of just showing the latest SQL command. singular "command" in pg_stat_activity ? > * `pg_settings.pending_restart` now show as true when a pertinent entry in > `postgresql.conf` is removed. "is now shown" > All PostgreSQL update releases are cumulative. As with other minor releases, > users are not required to dump and reload their database or use `pg_upgrade` in > order to apply this update release; you may simply shutdown PostgreSQL and shut down -- Justin
On 8/11/21 2:46 PM, Justin Pryzby wrote: > On Wed, Aug 11, 2021 at 12:32:41PM -0400, Jonathan S. Katz wrote: > >> * walsenders now show their latest replication commands in `pg_stat_activity`, >> instead of just showing the latest SQL command. > > singular "command" in pg_stat_activity ? Adjusted to be singular. > >> * `pg_settings.pending_restart` now show as true when a pertinent entry in >> `postgresql.conf` is removed. > > "is now shown" I went with the active voice: "now shows" >> All PostgreSQL update releases are cumulative. As with other minor releases, >> users are not required to dump and reload their database or use `pg_upgrade` in >> order to apply this update release; you may simply shutdown PostgreSQL and > > shut down Adjusted. Thanks, Jonathan
Attachment
Thanks for drafting this up. On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz <jkatz@postgresql.org> wrote: > Please ensure you have your feedback in no later than midnight today > (Aug 11) AoE[1]. It might not be the exact technical feedback you had in mind, but I think the following could be improved: + This release marks the third beta release of PostgreSQL 14 and puts the + community one step closer to general availability this fall. I think the above wording is pretty good if your audience was entirely based in, or at least expected to be based in North America. The people from the South of India might have been under the impression that the release was shortly after the monsoon season ended. The people from the Nothern parts of Australia likely think it's around when the wet season starts. The people from temperate parts of the Southern hemisphere think it's in the Spring. The people in the UK think it's in Autumn. I'd really like to see us move away from using seasons as an indicator of when something is occurring when the audience is based all over the world. Maybe something like "one step closer to general availability around the start of the final quarter of 2021" would have more meaning to the rest of the world? David
On 12/08/21 11:25 am, David Rowley wrote: > Thanks for drafting this up. > > On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz <jkatz@postgresql.org> wrote: >> Please ensure you have your feedback in no later than midnight today >> (Aug 11) AoE[1]. > It might not be the exact technical feedback you had in mind, but I > think the following could be improved: > > + This release marks the third beta release of PostgreSQL 14 and puts the > + community one step closer to general availability this fall. > > I think the above wording is pretty good if your audience was entirely > based in, or at least expected to be based in North America. The > people from the South of India might have been under the impression > that the release was shortly after the monsoon season ended. The > people from the Nothern parts of Australia likely think it's around > when the wet season starts. The people from temperate parts of the > Southern hemisphere think it's in the Spring. The people in the UK > think it's in Autumn. > > I'd really like to see us move away from using seasons as an indicator > of when something is occurring when the audience is based all over the > world. > > Maybe something like "one step closer to general availability around > the start of the final quarter of 2021" would have more meaning to the > rest of the world? > > David > > Living in New Zealand, I'd definitely agreed with not using seasons as they are hemispheric specific. Does anybody, other than the Americans, use 'Fall'' for Autumn???
On Wed, 11 Aug 2021 at 19:50, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
Living in New Zealand, I'd definitely agreed with not using seasons as
they are hemispheric specific.
Does anybody, other than the Americans, use 'Fall'' for Autumn???
Canadian here. We often use “Fall”, and we’re not Americans even though we are North Americans. But for the same reasons as others, I agree with the idea of using months or quarters (depending on how vague one wants to be!).
On 8/11/21 7:25 PM, David Rowley wrote: > Thanks for drafting this up. > > On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz <jkatz@postgresql.org> wrote: >> Please ensure you have your feedback in no later than midnight today >> (Aug 11) AoE[1]. > > It might not be the exact technical feedback you had in mind, but I > think the following could be improved: > > + This release marks the third beta release of PostgreSQL 14 and puts the > + community one step closer to general availability this fall. > > I think the above wording is pretty good if your audience was entirely > based in, or at least expected to be based in North America. This is a fair point, and elsewhere on the website we reference major releases occurring near the end of the third quarter. I've updated it to: "This release marks the third beta release of PostgreSQL 14 and puts the community one step closer to general availability around the end of the third quarter." Thanks, Jonathan
Attachment
On 8/11/21 8:53 PM, Jonathan S. Katz wrote: > On 8/11/21 7:25 PM, David Rowley wrote: > I've updated it to: > > "This release marks the third beta release of PostgreSQL 14 and puts the > community one step closer to general availability around the end of the > third quarter." And made another update: "This release marks the third beta release of PostgreSQL 14 and puts the community one step closer to general availability tentatively around the end of the third quarter." adding the qualifier "tentatively." Thanks, Jonathan