Add find_in_log() and advance_wal() perl functions to core test framework (?)
Hi,
It seems like find_in_log() and advance_wal() functions (which are now
being used in at least 2 places). find_in_log() is defined and being
used in 2 places 019_replslot_limit.pl and 033_replay_tsp_drops.pl.
The functionality of advancing WAL is implemented in
019_replslot_limit.pl with advance_wal() and 001_stream_repl.pl with
the same logic as advance_wal() but no function there and an
in-progress feature [1]/messages/by-id/CALj2ACUYz1z6QPduGn5gguCkfd-ko44j4hKcOMtp6fzv9xEWgw@mail.gmail.com needs advance_wal() as-is for tests.
Do these functions qualify to be added to the core test framework in
Cluster.pm? Or do we need more usages of these functions before we
generalize and add to the core test framework? If added, a bit of
duplicate code can be reduced and they become more usable across the
entire tests for future use.
Thoughts?
[1]: /messages/by-id/CALj2ACUYz1z6QPduGn5gguCkfd-ko44j4hKcOMtp6fzv9xEWgw@mail.gmail.com
--
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
On 2022-08-15 Mo 22:25, Bharath Rupireddy wrote:
Hi,
It seems like find_in_log() and advance_wal() functions (which are now
being used in at least 2 places). find_in_log() is defined and being
used in 2 places 019_replslot_limit.pl and 033_replay_tsp_drops.pl.
The functionality of advancing WAL is implemented in
019_replslot_limit.pl with advance_wal() and 001_stream_repl.pl with
the same logic as advance_wal() but no function there and an
in-progress feature [1] needs advance_wal() as-is for tests.Do these functions qualify to be added to the core test framework in
Cluster.pm? Or do we need more usages of these functions before we
generalize and add to the core test framework? If added, a bit of
duplicate code can be reduced and they become more usable across the
entire tests for future use.Thoughts?
[1] /messages/by-id/CALj2ACUYz1z6QPduGn5gguCkfd-ko44j4hKcOMtp6fzv9xEWgw@mail.gmail.com
I don't think there's a hard and fast rule about it. Certainly the case
would be more compelling if the functions were used across different TAP
suites. The SSL suite has suite-specific modules. That's a pattern also
worth considering. e.g something like.
use FindBin qw($Bin);
use lib $Bin;
use MySuite;
and then you put your common routines in MySuite.pm in the same
directory as the TAP test files.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-Aug-16, Andrew Dunstan wrote:
I don't think there's a hard and fast rule about it. Certainly the case
would be more compelling if the functions were used across different TAP
suites. The SSL suite has suite-specific modules. That's a pattern also
worth considering. e.g something like.use FindBin qw($Bin);
use lib $Bin;
use MySuite;and then you put your common routines in MySuite.pm in the same
directory as the TAP test files.
Yeah, I agree with that for advance_wal. Regarding find_in_log, that
one seems general enough to warrant being in Cluster.pm -- consider
issues_sql_like, which also slurps_file($log). That could be unified a
little bit, I think.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
At Tue, 16 Aug 2022 18:40:49 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in
On 2022-Aug-16, Andrew Dunstan wrote:
I don't think there's a hard and fast rule about it. Certainly the case
would be more compelling if the functions were used across different TAP
suites. The SSL suite has suite-specific modules. That's a pattern also
worth considering. e.g something like.use FindBin qw($Bin);
use lib $Bin;
use MySuite;and then you put your common routines in MySuite.pm in the same
directory as the TAP test files.Yeah, I agree with that for advance_wal. Regarding find_in_log, that
one seems general enough to warrant being in Cluster.pm -- consider
issues_sql_like, which also slurps_file($log). That could be unified a
little bit, I think.
+1
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center