Re: Some regression tests for the pg_control_*() functions

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: Some regression tests for the pg_control_*() functions
Date: 2022-10-26 04:43:29
Message-ID: CALj2ACWpVVk4mhfs_M7JCSAEmt8=6m8TEoBEj0igcDC+O3NP4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 25, 2022 at 11:07 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Hi all,
>
> As mentioned in [1], there is no regression tests for the SQL control
> functions: pg_control_checkpoint, pg_control_recovery,
> pg_control_system and pg_control_init.
>
> It would be minimal to check their execution, as of a "SELECT FROM
> func()", still some validation can be done on its output as long as
> the test is portable enough (needs transparency for wal_level, commit
> timestamps, etc.).
>
> Attached is a proposal to provide some coverage. Some of the checks
> could be just removed, like the ones for non-NULL fields, but I have
> written out everything to show how much could be done.
>
> Thoughts?
>
> [1]: https://www.postgresql.org/message-id/YzY0iLxNbmaxHpbs@paquier.xyz

+1 for improving the test coverage. Is there a strong reason to
validate individual output columns rather than select count(*) > 0
from pg_control_XXXX(); sort of tests? If the intention is to validate
the pg_controlfile contents, we have pg_controldata to look at and
pg_control_XXXX() functions doing crc checks. If this isn't enough, we
can have the pg_control_validate() function to do all the necessary
checks and simplify the tests, no?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-10-26 06:06:17 Re: Move backup-related code to xlogbackup.c/.h
Previous Message Pavel Stehule 2022-10-26 04:26:26 Re: proposal: possibility to read dumped table's name from file