GNU bug report logs - #32297
[PATCH] make postgresql find its plugins

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32297 in the body.
You can then email your comments to 32297 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: guix-patches <at> gnu.org
Subject: [PATCH] make postgresql find its plugins
Date: Sat, 28 Jul 2018 17:58:15 +0200

[Message part 1 (text/plain, inline)]

Hi,

attached is a patch to make postgresql find its plugins. Actually, it
only makes it unable to follow symlinks, so we can provide a union of
postgresql and plugins to the postgresql service. I also attached an
example system configuration that shows how this works. Do you think
this is the right solution? The patch was taken from nixos and updated
for the current version of postgresql.

Note that the VM will have troubles loading the extensions with only
its 256MB memory by default. You should add more ram to it.

Inside the VM, you can test with:

psql -U postgres
> create database postgistest;
> \connect postgistest;
> create extension postgis;
> create extension postgis_topology;

no error, you now have an empty spatial database :)

An extension would be to have a procedure to build the union of
packages (postgresql and extensions) called by the postgresql service.
we would have an "extension" field that would contain a list of
packages that contain extensions for postgresql and the service would
build and use the union of postgresql and these extensions. WDYT?

[0001-gnu-postgresql-Fix-finding-extensions.patch (text/x-patch, attachment)]

[postgis.scm (text/x-scheme, attachment)]

Message #8 received at 32297 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: 32297 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: [PATCH] make postgresql find its plugins
Date: Fri, 14 Sep 2018 17:29:19 +0200

[Message part 1 (text/plain, inline)]

This looks good to me.

The extensions field is a good idea.

I also believe that after adding an extensions field it would be easier to
document this.

Do you think that it might be possible to list these extension packages
somehow, or even stop them being directly installable, noting to use the
extensions field in your service definition? Would that make sense?

[Message part 2 (text/html, inline)]

Message #11 received at 32297 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32297 <at> debbugs.gnu.org
Subject: Re: [PATCH] make postgresql find its plugins
Date: Fri, 14 Sep 2018 22:03:53 +0200

[Message part 1 (text/plain, inline)]

Le Fri, 14 Sep 2018 17:29:19 +0200,
Gábor Boskovits <boskovits <at> gmail.com> a écrit :

> This looks good to me.
> 
> The extensions field is a good idea.
> 
> I also believe that after adding an extensions field it would be
> easier to document this.

Here is a new series of 2 patches: the first one is unchanged (only
rebased to master) and the second one introduces the extensions field
and documents it. I added an example in the documentation.

> 
> Do you think that it might be possible to list these extension
> packages somehow, or even stop them being directly installable,
> noting to use the extensions field in your service definition? Would
> that make sense?

Extension packages still have to be visible for users to list them in
the new field, so it seems hard to hide them at the same time :) I
agree it would make sense to be able to list all such extensions, and
so is listing extensions to other packages. Maybe we can think of a
generic mechanism for that?

[0001-gnu-postgresql-Fix-finding-extensions.patch (text/x-patch, attachment)]

[0002-gnu-postgresql-Add-extensions.patch (text/x-patch, attachment)]

Message #14 received at 32297 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32297 <at> debbugs.gnu.org
Subject: Re: [bug#32297] [PATCH] make postgresql find its plugins
Date: Fri, 14 Sep 2018 22:14:07 +0200

[Message part 1 (text/plain, inline)]

Le Fri, 14 Sep 2018 22:03:53 +0200,
Julien Lepiller <julien <at> lepiller.eu> a écrit :

> Le Fri, 14 Sep 2018 17:29:19 +0200,
> Gábor Boskovits <boskovits <at> gmail.com> a écrit :
> 
> > This looks good to me.
> > 
> > The extensions field is a good idea.
> > 
> > I also believe that after adding an extensions field it would be
> > easier to document this.  
> 
> Here is a new series of 2 patches: the first one is unchanged (only
> rebased to master) and the second one introduces the extensions field
> and documents it. I added an example in the documentation.
> 
> > 
> > Do you think that it might be possible to list these extension
> > packages somehow, or even stop them being directly installable,
> > noting to use the extensions field in your service definition? Would
> > that make sense?  
> 
> Extension packages still have to be visible for users to list them in
> the new field, so it seems hard to hide them at the same time :) I
> agree it would make sense to be able to list all such extensions, and
> so is listing extensions to other packages. Maybe we can think of a
> generic mechanism for that?

Whoops, that last patch wasn't complete :)

[0002-gnu-postgresql-Add-extensions.patch (text/x-patch, attachment)]

Message #17 received at 32297 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32297 <at> debbugs.gnu.org
Subject: Re: [bug#32297] [PATCH] make postgresql find its plugins
Date: Fri, 14 Sep 2018 22:49:36 +0200

[Message part 1 (text/plain, inline)]

Le Fri, 14 Sep 2018 22:14:07 +0200,
Julien Lepiller <julien <at> lepiller.eu> a écrit :

> Le Fri, 14 Sep 2018 22:03:53 +0200,
> Julien Lepiller <julien <at> lepiller.eu> a écrit :
> 
> > Le Fri, 14 Sep 2018 17:29:19 +0200,
> > Gábor Boskovits <boskovits <at> gmail.com> a écrit :
> >   
> > > This looks good to me.
> > > 
> > > The extensions field is a good idea.
> > > 
> > > I also believe that after adding an extensions field it would be
> > > easier to document this.    
> > 
> > Here is a new series of 2 patches: the first one is unchanged (only
> > rebased to master) and the second one introduces the extensions
> > field and documents it. I added an example in the documentation.
> >   
> > > 
> > > Do you think that it might be possible to list these extension
> > > packages somehow, or even stop them being directly installable,
> > > noting to use the extensions field in your service definition?
> > > Would that make sense?    
> > 
> > Extension packages still have to be visible for users to list them
> > in the new field, so it seems hard to hide them at the same time :)
> > I agree it would make sense to be able to list all such extensions,
> > and so is listing extensions to other packages. Maybe we can think
> > of a generic mechanism for that?  
> 
> Whoops, that last patch wasn't complete :)

I must be really tired, I spotted more mistakes after trying to run
guix system on a config with postgis.

[0002-gnu-postgresql-Add-extensions.patch (text/x-patch, attachment)]

Message #20 received at 32297 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: 32297 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: make postgresql find its plugins
Date: Mon, 24 Sep 2018 13:23:38 +0200

[Message part 1 (text/plain, inline)]

It works fine for me.

Some things I noticed while checking this:
1. postgresql contrib extensions should not be listed, and are working even
without the patches. (This includes for example hstore, dblink,...
see https://www.postgresql.org/docs/current/static/contrib.html for the
full list)
Did not test if it is problem if one adds these to the config though.
2. I had postgis actually missing, due to a missing use module, but there
was no complaint, system reconfigure went just fine, but creating extension
postgis did not work. Can we add some way to check if the list supplied is
sane?
3. contrib extensions also work fine with the patches applied.
4. I did not test if it works if we have more than one extension, but it
looks good.
If we have any other extension packaged, we could take a look.
5. Do you think we should add a test?
6. I got a warning that the first patch introduces whitespace errors on
current master. Is that ok?

[Message part 2 (text/html, inline)]

Message #25 received at 32297-done <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32297-done <at> debbugs.gnu.org
Subject: Re: make postgresql find its plugins
Date: Thu, 4 Oct 2018 22:36:47 +0200

Le Mon, 24 Sep 2018 13:23:38 +0200,
Gábor Boskovits <boskovits <at> gmail.com> a écrit :

> It works fine for me.
> 
> Some things I noticed while checking this:
> 1. postgresql contrib extensions should not be listed, and are
> working even without the patches. (This includes for example hstore,
> dblink,... see
> https://www.postgresql.org/docs/current/static/contrib.html for the
> full list) Did not test if it is problem if one adds these to the
> config though. 2. I had postgis actually missing, due to a missing
> use module, but there was no complaint, system reconfigure went just
> fine, but creating extension postgis did not work. Can we add some
> way to check if the list supplied is sane?
> 3. contrib extensions also work fine with the patches applied.
> 4. I did not test if it works if we have more than one extension, but
> it looks good.
> If we have any other extension packaged, we could take a look.
> 5. Do you think we should add a test?
> 6. I got a warning that the first patch introduces whitespace errors
> on current master. Is that ok?

Pushed on staging since the changes to postgresql requires a lot of
rebuilds.

The whitespace error is located in parts of the patch I can't change.
I've also added a sentence to the manual to make it clear that you
should list packages and not extensions themselves, and that you don't
need to add contrib extensions in the field. Otherwise, I think I've
addressed all your comments :)

Thank you for your review!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.