Hi,
On 2022-10-03 00:42:27 +0900, Dong Wook Lee wrote:
> > Which indeed is the case, e.g. on 32bit systems it fails:
> >
> > https://cirrus-ci.com/task/4619535222308864?logs=test_world_32#L253
> >
> > https://api.cirrus-ci.com/v1/artifact/task/4619535222308864/testrun/build-32/testrun/pgstattuple/
> Which indeed is the case, e.g. on 32bit systems it fails:
>
> https://cirrus-ci.com/task/4619535222308864?logs=test_world_32#L253
>
> https://api.cirrus-ci.com/v1/artifact/task/4619535222308864/testrun/build-32/testrun/pgstattuple/regress/regression.diffs
>
> table_len | tuple_count | tuple_len
Hi,
On 2022-08-03 11:19:59 +0900, Dong Wook Lee wrote:
> Is there no problem with selecting all the columns during SELECT statements?
> I thought there might be a problem where the test results could change easily.
Which indeed is the case, e.g. on 32bit systems it fails:
https://cirrus-ci.com/t
Tom Lane writes:
> I do not think it's a great idea to create random dependencies
> between modules like the pgstattuple -> bloom dependency you
> casually added here.
I agree with your option.
Is there no problem with selecting all the columns during SELECT statements?
I thought there might be
Dong Wook Lee writes:
> Hi, hackers
> I added some SQL statements to improve test coverage.
I do not think it's a great idea to create random dependencies
between modules like the pgstattuple -> bloom dependency you
casually added here.
regards, tom lane
Hi, hackers
I added some SQL statements to improve test coverage.
As data was inserted, the expected file changed.
So should I change all `select *` for a stable expected result?
And it's the coverage change as I add
50.6% -> 78.7%
---
regards,
Lee Dong Wook
v1_add_test_pgstattuple.patch
Descrip
