
Problem/Motivation
Drupal 10+ added a requirement on the pg_trgm
extension when installed in PostgreSQL environments. See #3190516: [Policy] For PostgreSQL require that the pg_trgm extension is not only installed, but also created..
This means that site admins need to take an additional manual step between setting up their database and installing Drupal, by running this query on their database:
CREATE EXTENSION pg_trgm;
In PostgreSQL 12, this must be done by a database user with superadmin privileges.
In PostgreSQL 13+, however, the pg_trgm
extension has been designated as a "trusted extension" (a new concept added in 13: https://www.postgresql.org/docs/13/release-13.html#id-1.11.6.15.5.14), which means that it should be possible for Drupal to run the necessary query itself (using the less-privileged Drupal database user) during installation on a PostgreSQL 13+ database.
Proposed resolution
I propose we add some logic to Drupal's PostgreSQL database installation tasks that install the pg_trgm
extension automatically if the PostgreSQL version is 13+.
Remaining tasks
TBD.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
TBD.
Comment | File | Size | Author |
---|---|---|---|
#26 | 3349973-26.patch | 1008 bytes | arantxio |
Comments
Comment #2
m.stentaJust to kick things off, I sketched up a simple patch that demonstrates a potential approach to this. I don't know if it's the best place to put this, and I have NOT tested it with a fresh install yet. We'll also need tests, of course... but I figure it's worth getting a quick sanity check from others before spending time on it. :-)
Comment #3
daffie CreditAttribution: daffie at Finalist commentedCan we change
13
to'13.0.0'
. That is how the functionversion_compare()
works. See: https://www.php.net/manual/en/function.version-compare.php@m.stenta: Good find! Thanks.
Comment #4
akram khanadded updated patch and address #3
Comment #5
daffie CreditAttribution: daffie at Finalist commentedCan we change this to:
We should not go over the 80 characters per line. See: https://www.drupal.org/docs/develop/standards/php/php-coding-standards#l...
Comment #6
akram khanadded wrong file address comment #5 but still there is some issue
Comment #7
daffie CreditAttribution: daffie at Finalist commented@Akram Khan: I have updated my comment #5. Thank you for responding so fast to my review. It was a bit too fast. ;) Could you update the patch a second time?
Comment #8
akram khanyes @daffie sorry for that
Comment #9
daffie CreditAttribution: daffie at Finalist commentedI have asked to the testbot maintainer @hestenet on Drupal Slack for a testbot with PostgreSQL 12 and PHP 8.1. As this is a fix for PostgreSQL 13 and higher, we should make sure that it works with PostgreSQL 12. As for Drupal 10 the minimum required version for PostgreSQL is 12.
Comment #10
daffie CreditAttribution: daffie at Finalist commentedCould you remove "version for" from the end of the line. Thank for working on this issue.
Comment #11
akram khanSorry for the wrong file that i added @daffie now address your comment
Comment #12
akram khanComment #13
m.stentaGreat to see this moving!
Adding the "Needs tests" flag, because I assume that is needed. :-)
Credit where credit is due... @wotnak described this in #3270558: Install and create the postgres pg_trgm extension in docker container starting with this comment: https://www.drupal.org/project/farm/issues/3270558#comment-14958332
@daffie are you able to add @wotnak to the credits on this issue? I think he should be included.
Comment #14
m.stentaHow would we go about testing this, I wonder... ?
I found this related issue: #3186676: Create the pg_trgm extension on PostgreSQL 10.12 and 12.1 database environments
... which explicitly enables the
pg_trgm
in drupal.org testing environments for PostgreSQL 10.12 and 12.1 environments.It looks like the PostgreSQL 13.5 and 14.1 environments are enabling it as well:
I suppose the best way to test this would be to remove those lines from the 13.5 and 14.1
startup.sh
scripts, and see if the tests still pass. Can't do that... because it would cause all other tests on those environments to start failing without this patch.Although... that's assuming that Drupal core has automated tests that would fail if the
pg_trgm
extension is not enabled. I assume it would, but I haven't confirmed...Bit of a chicken and egg problem? :-)
Comment #15
smustgrave CreditAttribution: smustgrave at Mobomo commentedShout out to hestenet for adding the new postgre test combos
I'm seeing all green and believe that's what was needed.
Comment #17
daffie CreditAttribution: daffie at Finalist commentedGiving @hestenet issue credit for setting up the testbot with PHP 8.1 en PostgreSQL 12.
Comment #19
daffie CreditAttribution: daffie at Finalist commentedGiving @wotnak issue credits for his work in #3270558: Install and create the postgres pg_trgm extension in docker container.
Comment #20
quietone CreditAttribution: quietone at PreviousNext commented@todo statements should have a link to an issue, see @todo: To Do notes. That helps them be found and reduce the risk of duplicates. There isn't an issue for this yet, as can be seen in #3214954: [11.x] [meta] Set Drupal 11 platform and browser requirements at least six months before the release.
This can be simpler, "Enable pg_trgrm for PostgreSQL 13 or higher."
This is comparing with '13.0.0' but the PostgreSQL docs state that the version numbers are 2 digits. And this is supported by the lists of versions at https://www.postgresql.org/docs/release/13.0/. I use ddev and the installed version was "13.10 (Debian 13.10-1.pgdg110+1)" which is also two digits. So, if I was running 13.0 this would return false and the extension would not be installed. If it really is two digits then this should be changed.
Comment #21
arantxioThe comments in #20 by quietone should be addressed with this patch.
As stated in #20.3 the versions since postgre 10 are now 2 digits. for example "13.10" or "15.2". So I've adjusted this check.
Comment #22
daffie CreditAttribution: daffie at Finalist commentedAll points of @quietone have been addressed.
Back to RTBC.
Comment #23
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedI have tested this manually and I am not sure how is this supposed to work? When I create a database manually (without pg_trgm), and try to install Drupal with this patch, then on the first form submit (on the setup database step) I get an error:
If I submit the form second time, the error is gone and the installation will continue. Is it possible that the extension is created only after the requirements check triggered the error already? See here:
Tested on PostgreSQL 13, with non-superuser account.
Comment #24
m.stentaThanks for testing manually @poker10. Maybe the d.o automated tests don't pick this up because they work differently than a UI-based install?
I imagine
checkExtensions()
needs to check the PostgreSQL version as well, and only raise the error on versions less than 13.Comment #25
daffie CreditAttribution: daffie at Finalist commented@poker10: Thanks!
Comment #26
arantxioThe following patch moves the code to enable the extension to the checkExtensions function. The code only runs once during site installation so it doesn't matter that we put it here. Also it wont enable the extension if it already exist.
Comment #27
daffie CreditAttribution: daffie at Finalist commentedMoved the creation of the extension to before the checking of the extension exists.
Back to RTBC.
Comment #28
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedTested this manually with unprivileged user and installation on both databases (with and without the extension enabled) completed successfully. +1 for this patch. Thanks!
Comment #31
longwaveCommitted and pushed c9412349f8 to 11.x (10.2.x). Thanks!
Comment #32
andypostCould use release note or CR
Comment #33
longwaveAdded CR: https://www.drupal.org/node/3368754
Not sure it is worth a release note, it only affects new installs.