Re: 2021-08-12 release announcement draft

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 2021-08-12 release announcement draft
Date: 2021-08-11 18:42:38
Message-ID: a4516c82-94c7-a4c3-84b5-338bab01fcc9@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/11/21 2:29 PM, Peter Geoghegan wrote:
> On Wed, Aug 11, 2021 at 11:23 AM Jonathan S. Katz <jkatz(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-08-11 18:45:12 Re: 2021-08-12 release announcement draft
Previous Message Peter Geoghegan 2021-08-11 18:29:24 Re: 2021-08-12 release announcement draft