2021-08-12 release announcement draft

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

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

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

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

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