Re: Autovacuum on partitioned table (autoanalyze) - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Autovacuum on partitioned table (autoanalyze)
Date
Msg-id 202108161700.d4eh6a7n2lki@alvherre.pgsql
Whole thread Raw
In response to Re: Autovacuum on partitioned table (autoanalyze)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Autovacuum on partitioned table (autoanalyze)  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 2021-Aug-16, Tom Lane wrote:

> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org> writes:
> > Here's the reversal patch for the 14 branch.  (It applies cleanly to
> > master, but the unused member of PgStat_StatTabEntry needs to be
> > removed and catversion bumped).
> 
> I don't follow the connection to catversion?

Sorry, I misspoke -- I mean PGSTAT_FORMAT_FILE_ID.  I shouldn't just
change it, since if I do then the file is reported as corrupted and all
counters are lost.  So in the posted patch I did as you suggest:

> I agree that we probably don't want to change PgStat_StatTabEntry in
> v14 at this point.  But it'd be a good idea to attach a comment to
> the entry saying it's unused but left there for ABI reasons.

It's only in branch master that I'd change the pgstat format version and
remove the field.  This is what I meant with the patch being for v14 and
a tweak needed for this in master.

A catversion bump would be required to change the definition of
pg_stat_user_tables, which the patch being reverted originally changed
to include relkind 'p'.  A straight revert would remove that, but in my
reversal patch I chose to keep it in place.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
sólo le suma el nuevo terror de la locura" (Perelandra, C.S. Lewis)



pgsql-hackers by date:

Previous
From: Hans Buschmann
Date:
Subject: AW: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode
Next
From: Jacob Champion
Date:
Subject: Re: badly calculated width of emoji in psql