Re: pg_amcheck option to install extension - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: pg_amcheck option to install extension
Date
Msg-id AEFF2AFC-7DB2-443E-BBE3-B15C684BA15C@enterprisedb.com
Whole thread Raw
In response to pg_amcheck option to install extension  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_amcheck option to install extension  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

> On Apr 16, 2021, at 11:06 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> Hi,
>
> Peter Geoghegan suggested that I have the cross version upgrade checker
> run pg_amcheck on the upgraded module. This seemed to me like a good
> idea, so I tried it, only to find that it refuses to run unless the
> amcheck extension is installed. That's fair enough, but it also seems to
> me like we should have an option to have pg_amcheck install the
> extension is it's not present, by running something like 'create
> extension if not exists amcheck'. Maybe in such a case there could also
> be an option to drop the extension when pg_amcheck's work is done - I
> haven't thought through all the implications.
>
> Given pg_amcheck is a new piece of work I'm not sure if we can sneak
> this in under the wire for release 14. I will certainly undertake to
> review anything expeditiously. I can work around this issue in the
> buildfarm, but it seems like something other users are likely to want.

We cannot quite use a "create extension if not exists amcheck" command, as we clear the search path and so must specify
theschema to use.  Should we instead avoid clearing the search path for this?  What are the security implications of
usingthe first schema of the search path? 

When called as `pg_amcheck --install-missing`, the implementation in the attached patch runs per database being checked
a"create extension if not exists amcheck with schema public".  If called as `pg_amcheck --install-missing=foo`, it
insteadruns "create extension if not exists amcheck with schema foo` having escaped "foo" appropriately for the given
database. There is no option to use different schemas for different databases.  Nor is there any option to use the
searchpath.  If somebody needs that, I think they can manage installing amcheck themselves. 

Does this meet your needs for v14?  I'd like to get this nailed down quickly, as it is unclear to me that we should
evenbe doing this so late in the development cycle. 

I'd also like your impressions on whether we're likely to move contrib/amcheck into core anytime soon.  If so, is it
worthadding an option that we'll soon need to deprecate? 



—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "could not find pathkey item to sort" for TPC-DS queries 94-96
Next
From: Tom Lane
Date:
Subject: Re: feature request ctid cast / sql exception