On Tue, Jan 28, 2025 at 01:33:58PM +0300, Aleksander Alekseev wrote:
> Thanks for your feedback!
set_masklen(inet) could be covered for the -1 case, and it was missing
in the patch submitted. For consistency with the other queries,
moving the call of abbrev(inet) with the existing abbrev(cidr) ma
Hi,
> The correct version is as follows.
>
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation: tested, passed
Thanks for your feedback!
> About the tests pushed to the SSL test suite, I'm +-0. 003_sslinfo.pl
> is a bit
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, failed
> Spec compliant: tested, failed
> Documentation:tested, failed
Sorry, I thought I checked with the commitfest App,
On Tue, Jan 28, 2025 at 07:24:38AM +, keisuke kuroda wrote:
> I have confirmed that the coverage improves
> to the expected value(69.7%->83.0%)
>
> source: commit 75eb9766ec201b62f264554019757716093e2a2f(HEAD)
> ## add with-openssl option for ssltest
> ./configure --enable-coverage --enable-t
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Thank you for your patch!
I have confirmed that the coverage
Hi everyone,
Many thanks for all your great feedback.
> In any case, Aleksander, I don't mean to sign you up for all that; the
> `ssl` suite also seems good enough to me if you're interested in
> pursuing that side of the patch further.
OK, I moved the named tests to src/test/ssl/t/003_sslinfo.p
On Mon, Jan 20, 2025 at 12:27 PM Tom Lane wrote:
> Part of my thought here is that these functions are not worth their
> very own TAP test, with all the overhead that implies of firing up
> a new database instance. So I was looking for something we could
> fold them into.
By themselves, yeah, pr
Jacob Champion writes:
> On Mon, Jan 20, 2025 at 11:35 AM Tom Lane wrote:
>> Maybe we could add this to the existing src/test/ssl/ tests,
>> which already deal with that hazard?
> That seems okay in the short term. (But it certainly highlights our
> lack of a "PG_TEST_EXTRA=loopback-is-fine" mod
On Mon, Jan 20, 2025 at 11:35 AM Tom Lane wrote:
> To do anything interesting, the test would have to make the server
> open a TCP port, which would be rightly seen as a security hazard.
> So it'd have to be confined to a not-run-by-default test case.
Yeah.
> Maybe we could add this to the exist
Jacob Champion writes:
> On Thu, Oct 31, 2024 at 9:30 AM Aleksander Alekseev
> wrote:
>> Recently I played with lcov [1]. In the process it was discovered that
>> the following functions are not executed by our tests:
>>
>> - abbrev(inet)
>> - set_masklen(cidr,int4)
>> - netmask(inet)
>> - hostm
On Thu, Oct 31, 2024 at 9:30 AM Aleksander Alekseev
wrote:
> Recently I played with lcov [1]. In the process it was discovered that
> the following functions are not executed by our tests:
>
> - abbrev(inet)
> - set_masklen(cidr,int4)
> - netmask(inet)
> - hostmask(inet)
The new tests for the fir
I could not send it to the mailing list, so I'm resending it.
___
Hi Aleksander,
I have tested your patch.
I have confirmed that the coverage improves
to the expected value(69.8%->80.1%)
Your patch looks good to me.
## test and make coverage
source: commit 9a45a89c38f3257b13e09edf382e32fa28b918c
Hi Stepan,
> Hello Aleksander! I'm a beginner and I would like to see and try your patch.
> However, I have never worked with coverage in regression tests for
> PostgreSQL. Could you please tell me how it works and help me understand the
> process? Thanks!
You are going to need some Linux dist
Hello Aleksander! I'm a beginner and I would like to see and try your
patch. However, I have never worked with coverage in regression tests for
PostgreSQL. Could you please tell me how it works and help me understand
the process? Thanks!
Best Regards, Stepan Neretin!
14 matches
Mail list logo