Re: Unit tests for SLRU

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Pavel Borisov <pashkin(dot)elfe(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-04-05 09:38:48
Message-ID: CAJ7c6TP+4FquwzZ_FGdLgRK2YRz9K76RAA7e6JnQkEbOT1GUwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Daniel,

> It also doesn't seem all that appealing that SimpleLruInit can
> return false on successful function invocation, it makes for a confusing
API.

Agree. I think using an additional `bool *found` argument would be less
confusing.

Noah, Pavel,

>> The default place for this kind of test is regress.c, with plain "make
check"
>> calling the regress.c function. src/test/modules is for things
requiring an
>> extension module or otherwise unable to run through regress.c.
>
> +1 for placement c functions into regress.c if it's possible for the aim
of simplification.

Thanks for your feedback. I'm OK with placing the tests to regress.c, but I
would like to double-check if this would be a right place for them.

I'm reading src/test/modules/README and it says:

"""
src/test/modules contains PostgreSQL extensions that are primarily or
entirely
intended for testing PostgreSQL and/or to serve as example code. [...]

If you're adding new hooks or other functionality exposed as C-level API
this
is where to add the tests for it.
"""

SLRU looks like a quite general-purpose container. I can imagine how
someone may decide to use it in an extension. Wouldn't it be more logical
to place it near:

src/test/modules/test_rbtree
src/test/modules/test_shm_mq

... etc?

Again, I don't have a strong opinion here. If you insist, I will place the
tests to regress.c.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-04-05 09:42:09 Re: Extensible Rmgr for Table AMs
Previous Message Kyotaro Horiguchi 2022-04-05 08:18:57 Re: standby recovery fails (tablespace related) (tentative patch and discussion)