Re: Add a perl function in Cluster.pm to generate WAL
От | Bharath Rupireddy |
---|---|
Тема | Re: Add a perl function in Cluster.pm to generate WAL |
Дата | |
Msg-id | CALj2ACU3R8QFCvDewHCMKjgb2w_-CMCyd6DAK=Jb-af14da5eg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Add a perl function in Cluster.pm to generate WAL
|
Список | pgsql-hackers |
On Wed, Aug 24, 2022 at 6:42 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > 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 With the generalized function for find_in_log() has been added as part of https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e25e5f7fc6b74c9d4ce82627e9145ef5537412e2, I'm proposing a generalized function for advance_wal(). Please find the attached patch. I tried to replace the existing tests with the new cluster function advance_wal(). Please let me know if I'm missing any other tests. Also, this new function can be used by an in-progress feature - https://commitfest.postgresql.org/43/3663/. Thoughts? FWIW, it's discussed here - https://www.postgresql.org/message-id/ZIKVd%2Ba43UfsIWJE%40paquier.xyz. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: