pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Julien Rouhaud <rjuju123@gmail.com>
To: Erica Zhang <ericazhangy@qq.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add some tests for pg_stat_statements compatibility verification under contrib
Date: Wed, 10 Mar 2021 11:35:53 +0800
Message-ID: <20210310033553.v5ajijyswer4ux5q@nol> (raw)
In-Reply-To: <tencent_A7EB5CAC90CA14BA65FA173D0B1A8FBC6F09@qq.com>
References: <tencent_BBA974AFF61379F2345E782FD6C55891950A@qq.com>
	<20210309090937.4eca74eme7jvcvhi@nol>
	<tencent_A7EB5CAC90CA14BA65FA173D0B1A8FBC6F09@qq.com>

Hi Erica,

On Wed, Mar 10, 2021 at 11:14:52AM +0800, Erica Zhang wrote:
> Hi Julien,
> Thanks a lot for the quick review. Please see my answer below in blue. Attached is the new patch.

Thanks!

>> The upgrade scripts are already tested as postgres will install 1.4 and perform
>> all upgrades to reach the default version.
> Thanks for pointing that the upgrades paths are covered by upgrade scripts tests. Since I don't need to test the upgrade, I will test the installation of different versions directly, any concern?

I think you should keep your previous approach.  The result will be the same
but it will consume less resources for that which is always good.

>> +SELECT * FROM pg_available_extensions WHERE name = 'pg_stat_statements' and installed_version = '1.4';
>> 
>> 
>> What is this supposed to test?&nbsp; All those tests will break every time we change
>> the default version, which will add maintenance efforts.&nbsp; It could be good to
>> have one test breaking when changing the version to remind us to add a test for
>> the new version, but not more.
> Here I just want to verify that "installed" version is the expected version. But we do have the issue as you mentioned which will add maintenance efforts. 
> 
> So I prefer to keep one test as now which can remind us to add a new version. As for others, just to check the count(*) to make sure installation is success.
> Such as SELECT count(*) FROM pg_available_extensions WHERE name = 'pg_stat_statements' and installed_version = '1.4'; What do you think?

How about tweaking your previous query so only the last execution fails when
pg_stat_statements default version is updated?  Something like:

SELECT installed_version = default_version, installed_version
FROM pg_available_extensions
WHERE name = 'pg_stat_statements';

This way the same query can be reused for both older versions and current
version.

Also, can you register your patch for the next commitfest at
https://commitfest.postgresql.org/33/, to make sure it won't be forgotten?





view thread (8+ messages)  latest in thread

Message-ID: <20210310033553.v5ajijyswer4ux5q@nol>
Permalink:  ../20210310033553.v5ajijyswer4ux5q@nol/
Also on:    postgresql.org/message-id/20210310033553.v5ajijyswer4ux5q@nol

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: rjuju123@gmail.com, ericazhangy@qq.com
  Subject: Re: Add some tests for pg_stat_statements compatibility verification under contrib
  In-Reply-To: <20210310033553.v5ajijyswer4ux5q@nol>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox