Re: TAP test utility module 'PG_LSN.pm'

From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test utility module 'PG_LSN.pm'
Date: 2020-12-01 06:11:08
Message-ID: CAGRY4nwtXyOrsoy1QR_3gVyaThf2+65awEDze6GL+Pm=-0cRyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 1 Dec 2020 at 13:58, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Dec 01, 2020 at 12:03:41PM +0800, Craig Ringer wrote:
> > I'd like to share the attached PG_LSN.pm module that I use when
> > writing TAP tests. I suggest that it be considered for inclusion in
> > core.
> >
> > It defines a Perl datatype PG_LSN with operator support, so you can
> > write things like
> >
> > cmp_ok($got_lsn, "<", $expected_lsn, "testname")
> >
> > in TAP tests and get sensible results without any concern for LSN
> > representation details, locale, etc. You can subtract LSNs to get a
> > byte difference too.
>
> In my experience, any TAP tests making use of LSN operations can just
> let the backend do the maths, so I am not much a fan of duplicating
> that stuff in a perl module. Wouldn't it be better to add an
> equivalent of your add() function in the backend then? That could
> also get tested in the main regression test suite.

I find it convenient not to have as much log spam. Also, IIRC I needed
it at some points where the target backend(s) were down while I was
testing something related to a backend that was still in recovery and
not yet available for querying.

I don't really mind though, I'm just sharing what I have found useful.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-12-01 06:14:06 Re: TAP test utility module 'PG_LSN.pm'
Previous Message Michael Paquier 2020-12-01 06:10:13 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly