> The only thing that I can think of would be if $decompress_program
> --test were failing, but actually trying to decompress succeeded. I
> would be inclined to dismiss that particular scenario as not important
> enough to be worth the additional CPU cycles.
When I wrote this test, it was just to
2022年12月5日(月) 23:59 Robert Haas :
>
> On Fri, Dec 2, 2022 at 11:29 PM Ian Lawrence Barwick
> wrote:
> > Though on reflection maybe it's overkill and the existing tests
> > suffice. Anyway leaving the patch here in the interests of pushing
> > this forward in some direction.
>
> Do you think that
On Fri, Dec 2, 2022 at 11:29 PM Ian Lawrence Barwick wrote:
> Though on reflection maybe it's overkill and the existing tests
> suffice. Anyway leaving the patch here in the interests of pushing
> this forward in some direction.
Do you think that there is a scenario where 008_untar.pl and
009_ext
Hi
I was looking at the commitfest entry for this patch [1] as it's been dormant
for quite a while, with the intent of returning it with feedback.
[1] https://commitfest.postgresql.org/40/3835/
2022年8月25日(木) 16:52 Dong Wook Lee :
>
> On Tue, Aug 23, 2022 at 11:37 AM Michael Paquier wrote:
>
> >
On Thu, Aug 25, 2022 at 3:52 AM Dong Wook Lee wrote:
> Could you check if I missed anything?
There is already a far better test for this in
src/bin/pg_verifybackup/t/009_extract.pl
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 23, 2022 at 11:37 AM Michael Paquier wrote:
> It seems to me that checking that the contents generated are valid is
> equally necessary. We do that with zlib with gzip --test, and you
> could use ${ZSTD} in the context of this test.
Thank you for the good points.
I supplemented the
On Tue, Aug 23, 2022 at 10:58:22AM +0900, Dong Wook Lee wrote:
> I checked the test code not to test the zstd option, then added it.
> I hope my patch will help us to ensure safety of the test.
It seems to me that checking that the contents generated are valid is
equally necessary. We do that wit
