On Sat, Nov 26, 2022 at 4:32 AM Andres Freund <andres@anarazel.de> wrote:
>
Thanks Andres for reviewing.
> > May I know what it means to deprecate pg_stat_bgwriter columns?
>
> Add a note to the docs saying that the columns will be removed.
Done.
> > Are
> > you suggesting to add deprecation warnings to corresponding functions
> > pg_stat_get_bgwriter_buf_written_clean(),
> > pg_stat_get_bgwriter_maxwritten_clean(), pg_stat_get_buf_alloc() and
> > pg_stat_get_bgwriter_stat_reset_time() and in the docs?
>
> I'm thinking of the checkpoint related columns in pg_stat_bgwriter.
Added note in the docs alongside each deprecated pg_stat_bgwriter's
checkpoint related column.
> If we move, rather than duplicate, the pg_stat_bgwriter columns to
> pg_stat_checkpointer, everyone will have to update their monitoring scripts
> when upgrading and will need to add version dependency if they monitor
> multiple versions. If we instead keep the duplicated columns in
> pg_stat_bgwriter for 5 years, users can reloy on pg_stat_checkpointer in all
> supported versions.
Agree. However, it's a bit difficult to keep track of deprecated
things and come back after 5 years to clean them up unless "some"
postgres hacker/developer/user notices it again. Perhaps, adding a
separate section, say 'Deprecated and To-Be-Removed, in
https://wiki.postgresql.org/wiki/Main_Page is a good idea.
> To be clear, it isn't a very heavy burden for users to make these
> adjustments. But if it only costs us a few lines to keep the old columns for a
> bit, that seems worth it.
Yes.
I'm attaching the v3 patch for further review.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
