Re: [HACKERS] Where to load modules from?

Robert Haas escribió: > On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut wrote: > > On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: > >> Peter Eisentraut writes: > >> > It shouldn't be in the commit fest if it has no patch. > >> > >> What should I do if my goal is to get community co

Re: [HACKERS] Where to load modules from?

On 2013-09-20 14:35:31 +0200, Dimitri Fontaine wrote: > Robert Haas writes: > > So... our usual comma-separated GUC syntax? Empty means no extra > > places to search. +1. > The only advantage of using an initdb place would have been the > opportunity to actually register modules and WAL log tha

Re: [HACKERS] Where to load modules from?

Robert Haas writes: > So... our usual comma-separated GUC syntax? Empty means no extra > places to search. Sounds pretty good to me. The only advantage of using an initdb place would have been the opportunity to actually register modules and WAL log that step so that the standby pg_modules dire

Re: [HACKERS] Where to load modules from?

On Fri, Sep 20, 2013 at 8:10 AM, Andres Freund wrote: > On 2013-09-20 08:06:56 -0400, Robert Haas wrote: >> On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund >> wrote: >> > Because I want to specify multiple paths. E.g. one with modules for a >> > specific postgres version, one for the cluster and

Re: [HACKERS] Where to load modules from?

On 2013-09-20 08:06:56 -0400, Robert Haas wrote: > On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund wrote: > > Because I want to specify multiple paths. E.g. one with modules for a > > specific postgres version, one for the cluster and one for my > > development directory. > > Now we could recursive

Re: [HACKERS] Where to load modules from?

On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund wrote: > On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote: >> Robert Haas writes: >> >> I think I'd prefer a GUC that allows specifying multiple directories >> >> that are searched in order to a single symlinked directory. >> > >> > Why? >> > >>

Re: [HACKERS] Where to load modules from?

On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote: > Robert Haas writes: > >> I think I'd prefer a GUC that allows specifying multiple directories > >> that are searched in order to a single symlinked directory. > > > > Why? > > > > I ask because I have the opposite preference, based on the pre

Re: [HACKERS] Where to load modules from?

Robert Haas writes: >> I think I'd prefer a GUC that allows specifying multiple directories >> that are searched in order to a single symlinked directory. > > Why? > > I ask because I have the opposite preference, based on the precedent of > pg_xlog. I understand Andres preference, as it would a

Re: [HACKERS] Where to load modules from?

On Wed, Sep 18, 2013 at 12:53 PM, Andres Freund wrote: > On 2013-09-18 08:46:08 -0400, Robert Haas wrote: >> Here's another idea. At initdb time, create an empty directory called >> called pg_you_can_load_stuff_from_here (pick a better name) inside >> $PGDATA. Allow it to be replaced with a syml

Re: [HACKERS] Where to load modules from?

On 2013-09-18 08:46:08 -0400, Robert Haas wrote: > Here's another idea. At initdb time, create an empty directory called > called pg_you_can_load_stuff_from_here (pick a better name) inside > $PGDATA. Allow it to be replaced with a symlink. This would be > similar to what we do today with pg_xlo

Re: [HACKERS] Where to load modules from?

Robert Haas writes: > I think that would largely be rehashing previous discussions, in which > it's already been established that we don't see eye to eye on this > issue. But briefly, I think that replacing shared libraries ought to Partly yes, but as I'm feeling that we are getting closer than

Re: [HACKERS] Where to load modules from?

On Wed, Sep 18, 2013 at 9:26 AM, Dimitri Fontaine wrote: > Robert Haas writes: >>> - consider on-disk extension as templates and move their module files >>> somewhere private in $PGDATA and load the code from there >> >> I think this will be horrid mess of security vulnerabilities and upgra

Re: [HACKERS] Where to load modules from?

Robert Haas writes: >> - consider on-disk extension as templates and move their module files >> somewhere private in $PGDATA and load the code from there > > I think this will be horrid mess of security vulnerabilities and upgrade woes. I think it's a solution to that horrid mess. Care to e

Re: [HACKERS] Where to load modules from?

On Sat, Sep 14, 2013 at 4:15 PM, Dimitri Fontaine wrote: > We can attack the problem in several ways: > > - have an initdb switch to tweak the library path per cluster, I see no advantage to making this impossible to change after initdb time. > - have a superuser-only GUC to tweak the librar

Re: [HACKERS] Where to load modules from?

On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut wrote: > On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: >> Peter Eisentraut writes: >> > It shouldn't be in the commit fest if it has no patch. >> >> What should I do if my goal is to get community consensus on the best >> way to solv

Re: [HACKERS] Where to load modules from?

On 15 Sep 2013 18:55, "Andrew Dunstan" wrote: > > > On 09/15/2013 05:52 PM, Jeff Janes wrote: > >> On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut > wrote: >> >> On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: >> > >> > This proposal comes with no patch because I think we

Re: [HACKERS] Where to load modules from?

On 09/15/2013 05:52 PM, Jeff Janes wrote: On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut > wrote: On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > This proposal comes with no patch because I think we are able to > understand it without th

Re: [HACKERS] Where to load modules from?

On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut wrote: > On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > > > This proposal comes with no patch because I think we are able to > > understand it without that, so that it would only be a waste of > > everybody's time to attach code fo

Re: [HACKERS] Where to load modules from?

Peter Eisentraut writes: > Post it to the pgsql-hackers list. Well. I think I just did ;-) > I understand why using the commit fest process is attractive for this, > because it enables you to force the issue. But the point of the commit It enables me to have a slight chance of seeing the effor

Re: [HACKERS] Where to load modules from?

On 2013-09-15 17:03:10 +0200, Marko Tiikkaja wrote: > On 2013-09-15 16:51, Peter Eisentraut wrote: > >On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: > >>My understanding is that a Commit Fest is mainly about Reviewing, that's > >>why I still added an entry for two designs that I need fe

Re: [HACKERS] Where to load modules from?

On 2013-09-15 16:51, Peter Eisentraut wrote: On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: My understanding is that a Commit Fest is mainly about Reviewing, that's why I still added an entry for two designs that I need feedback on before actually coding a solution. Writing the code

Re: [HACKERS] Where to load modules from?

On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: > Peter Eisentraut writes: > > It shouldn't be in the commit fest if it has no patch. > > What should I do if my goal is to get community consensus on the best > way to solve a problem, and want to start the discussion with some > proposa

Re: [HACKERS] Where to load modules from?

Peter Eisentraut writes: > It shouldn't be in the commit fest if it has no patch. What should I do if my goal is to get community consensus on the best way to solve a problem, and want to start the discussion with some proposals? My understanding is that a Commit Fest is mainly about Reviewing,

Re: [HACKERS] Where to load modules from?

On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > This proposal comes with no patch because I think we are able to > understand it without that, so that it would only be a waste of > everybody's time to attach code for a random solution on the list here > to that email. It shouldn't

Re: [HACKERS] Where to load modules from?

On 2013-09-14 22:15:58 +0200, Dimitri Fontaine wrote: > The way they make that safe is by using cgroups and SELinux, IIUC. > > We can attack the problem in several ways: > > - have an initdb switch to tweak the library path per cluster, That sounds like an utterly horrible idea without any adv

[HACKERS] Where to load modules from?

Hi, This topic gets back at every release, more often now that we have proper Extensions with ability to dump&restore. Lately the guys from Open Shift project (a Red Hat team) have asked for a way to load DSO module files from user-owned directory. The way they make that safe is by using cgroups