From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: Unit tests for SLRU |
Date: | 2022-11-14 11:19:08 |
Message-ID: | Y3IkLPWdhGWlMMvJ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 11, 2022 at 02:11:08PM +0900, Michael Paquier wrote:
> Is there a reason why you need a TAP test here? It is by design more
> expensive than pg_regress and it does not require --enable-tap-tests.
> See for example what we do for snapshot_too_old, commit_ts,
> worker_spi, etc., where each module uses a custom configuration file.
I have put my hands on that, and I found that the tests were a bit
overengineered. First, SimpleLruDoesPhysicalPageExist() is not that
much necessary before and after each operation, like truncation or
deletion, as the previous pages were doing equal tests. The hardcoded
page number lacks a bit of flexibility and readability IMO, especially
when combined with the number of pages per segments, as well.
I have reworked that as per the attached, that provides basically the
same coverage, going through a SQL interface for the whole thing.
Like all the other tests of its kind, this does not use a TAP test,
relying on a custom configuration file instead. This still needs some
polishing, but the basics are here.
What do you think?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
v6-0001-Add-unit-tests-for-SLRU.patch | text/x-diff | 17.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2022-11-14 11:25:34 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Antonin Houska | 2022-11-14 11:07:48 | Re: Privileges on PUBLICATION |