pgsql: Remove testing for precise LSN/reserved bytes in new TAP test

At Wed, 08 Apr 2020 03:33:04 +0000, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in

Remove testing for precise LSN/reserved bytes in new TAP test

Trying to ensure that a slot's restart_lsn or amount of reserved bytes
exactly match some specific values seems unnecessary, and fragile as
shown by failures in multiple buildfarm members.

Sorry for the wrong test file.
Checking in lower precision would be sufficient.

--
Kyotaro Horiguchi
NTT Open Source Software Center

At Wed, 08 Apr 2020 14:44:52 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in

At Wed, 08 Apr 2020 03:33:04 +0000, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in

Remove testing for precise LSN/reserved bytes in new TAP test

Trying to ensure that a slot's restart_lsn or amount of reserved bytes
exactly match some specific values seems unnecessary, and fragile as
shown by failures in multiple buildfarm members.

Sorry for the wrong test file.
Checking in lower precision would be sufficient.

I noticed that prailiedog failed in another mode.

not ok 5 - check that max_slot_wal_keep_size is working

# Failed test 'check that max_slot_wal_keep_size is working'
# at t/019_replslot_limit.pl line 89.
# got: '0/D00198|normal|5120 kB'
# expected: '0/D00164|normal|5120 kB'

The first colomn in the result is restart_lsn and it's not essential
to the test. It is removed in the attached test script. Precise LSN is
not reffered in tht test script.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:

Sorry for the wrong test file.
Checking in lower precision would be sufficient.

I noticed that prailiedog failed in another mode.

Yeah. We have at least four different buildfarm members complaining
about this test case. I took this patch and further lobotomized the
tests by removing *all* dependencies on restart_lsn and
pg_current_wal_lsn(). If anybody wants to put any of that back,
the burden of proof will be on them to show why we should believe
the results will be stable, not for the buildfarm to demonstrate
that they're not.

regards, tom lane

At Thu, 09 Apr 2020 17:31:59 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:

Sorry for the wrong test file.
Checking in lower precision would be sufficient.

I noticed that prailiedog failed in another mode.

Yeah. We have at least four different buildfarm members complaining
about this test case. I took this patch and further lobotomized the
tests by removing *all* dependencies on restart_lsn and
pg_current_wal_lsn(). If anybody wants to put any of that back,
the burden of proof will be on them to show why we should believe
the results will be stable, not for the buildfarm to demonstrate
that they're not.

I think the significant part of the test is wal_status. So I'm not
eager to get it back.

Thanks!

--
Kyotaro Horiguchi
NTT Open Source Software Center

On 2020-Apr-10, Kyotaro Horiguchi wrote:

Yeah. We have at least four different buildfarm members complaining
about this test case. I took this patch and further lobotomized the
tests by removing *all* dependencies on restart_lsn and
pg_current_wal_lsn(). If anybody wants to put any of that back,
the burden of proof will be on them to show why we should believe
the results will be stable, not for the buildfarm to demonstrate
that they're not.

I think the significant part of the test is wal_status. So I'm not
eager to get it back.

Agreed. Thanks for stabilizing it.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services