On 3/28/20 1:45 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On 3/22/20 1:08 AM, Andrew Dunstan wrote:
>>> Latest patch attached, I think all comments have been addressed. I
>>> propose to push this later this coming week if there are no more comments.
>> I do not have any objections.
> Thi
Andreas Karlsson writes:
> On 3/22/20 1:08 AM, Andrew Dunstan wrote:
>> Latest patch attached, I think all comments have been addressed. I
>> propose to push this later this coming week if there are no more comments.
> I do not have any objections.
This CF entry is still open, should it not be c
On 3/22/20 1:08 AM, Andrew Dunstan wrote:
Latest patch attached, I think all comments have been addressed. I
propose to push this later this coming week if there are no more comments.
I do not have any objections.
Andreas
On 3/21/20 9:18 AM, Andrew Dunstan wrote:
> On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
>
>
>
>> Trailing space:
>>
>> 220 + X509v3 Subject Key Identifier:
>> 222 + X509v3 Authority Key Identifier:
>
> We're going to remove all the text, so this becomes moot.
>
>
>> M
On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
> Trailing space:
>
> 220 + X509v3 Subject Key Identifier:
> 222 + X509v3 Authority Key Identifier:
We're going to remove all the text, so this becomes moot.
>
> Missing "d"(password?):
>
> 121 +/* init hook for SSL,
On 3/15/20 10:14 PM, Andreas Karlsson wrote:
> On 2/18/20 11:39 PM, Andrew Dunstan wrote:
>> This should fix the issue, it happened when I switched to using a
>> pre-generated cert/key.
>
> # Review
>
> The patch still applies and passes the test suite, both with openssl
> enabled and with it dis
Hello Andrew,
From: Andreas Karlsson
> # Nitpicking
>
> The certificate expires in 2030 while all other certificates used in
> tests expires in 2046. Should we be consistent?
>
> There is text in server.crt and server.key, while other certificates and
> keys used in the tests do not have this.
On 2/18/20 11:39 PM, Andrew Dunstan wrote:
This should fix the issue, it happened when I switched to using a
pre-generated cert/key.
# Review
The patch still applies and passes the test suite, both with openssl
enabled and with it disabled.
As for the feature I agree that it is nice to expo
On Wed, Feb 19, 2020 at 7:10 AM Andrew Dunstan
wrote:
>
> On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
> >
> > On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> > wrote:
> > > Not sure if the placement is what you want, but maybe something like this?
> >
> > Hi Andrew, FYI this failed here
On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
>
> On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> wrote:
> > Not sure if the placement is what you want, but maybe something like this?
>
> Hi Andrew, FYI this failed here:
>
> t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_
On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
wrote:
> Not sure if the placement is what you want, but maybe something like this?
Hi Andrew, FYI this failed here:
t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl
start failed
FAILED--Further testing stopped: pg_ctl start fail
On Thu, Nov 14, 2019 at 8:54 AM Sehrope Sarkuni wrote:
> Has the idea of using environment variables (rather than command line
> args) for external commands been brought up before? I couldn't find
> anything in the mailing list archives.
Passing data through environment variables isn't secure. Tr
On Sun, Dec 8, 2019 at 9:02 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Well that pretty much brings us back to the patch as submitted :-)
>
> Yeah, pretty nearly. Taking a quick look over the v3 patch, my
> only quibble is that it doesn't provide any convenient way for the
> external modu
On Sat, 7 Dec 2019 at 07:21, Tom Lane wrote:
> Andrew Dunstan writes:
> > I've just been looking at that. load_external_function() doesn't
> > actually do anything V1-ish with the value, it just looks up the symbol
> > using dlsym and returns it cast to a PGFunction. Is there any reason I
> > ca
Andrew Dunstan writes:
> Well that pretty much brings us back to the patch as submitted :-)
Yeah, pretty nearly. Taking a quick look over the v3 patch, my
only quibble is that it doesn't provide any convenient way for the
external module to make decisions about how to interact with
ssl_passphras
On 12/7/19 12:16 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Bruce was worried about what would happen if we defined both
>> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
>> let's the callback have precedence, but it might be cleaner to error out
>> with such a conf
Andrew Dunstan writes:
> Bruce was worried about what would happen if we defined both
> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
> let's the callback have precedence, but it might be cleaner to error out
> with such a config. OTOH, that wouldn't be so nice on a reloa
On 12/6/19 6:20 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've just been looking at that. load_external_function() doesn't
>> actually do anything V1-ish with the value, it just looks up the symbol
>> using dlsym and returns it cast to a PGFunction. Is there any reason I
>> can't just use
Andrew Dunstan writes:
> I've just been looking at that. load_external_function() doesn't
> actually do anything V1-ish with the value, it just looks up the symbol
> using dlsym and returns it cast to a PGFunction. Is there any reason I
> can't just use that and cast it again to the callback funct
On 11/15/19 8:59 AM, Andrew Dunstan wrote:
> On 11/14/19 3:21 PM, Alvaro Herrera wrote:
>> On 2019-Nov-14, Andrew Dunstan wrote:
>>
>>> I guess this would work. There would have to be a deal of code to load
>>> the library and lookup the symbol. Do we really think it's worth it?
>>> Leveraging sh
On Fri, 15 Nov 2019 at 00:34, Andrew Dunstan
wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> >> I think it would be beneficial to ex
On 11/14/19 3:21 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Andrew Dunstan wrote:
>
>> I guess this would work. There would have to be a deal of code to load
>> the library and lookup the symbol. Do we really think it's worth it?
>> Leveraging shared_preload_libraries makes this comparatively si
On 2019-Nov-14, Andrew Dunstan wrote:
> I guess this would work. There would have to be a deal of code to load
> the library and lookup the symbol. Do we really think it's worth it?
> Leveraging shared_preload_libraries makes this comparatively simple.
Using the generic interface has the drawback
On 11/14/19 12:07 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
>> I was assuming if the variable starts with a #, it is a shared object,
>> if not, it is a shell command:
>>
>> ssl_passphrase_command='#/lib/x.so'
>> ssl_passphrase_command='my_command a b c'
> Note
On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
> > I was assuming if the variable starts with a #, it is a shared object,
> > if not, it is a shell command:
> >
> > ssl_passphrase_command='#/lib/x.so'
> > ssl_passphrase_command='my
On 2019-Nov-14, Bruce Momjian wrote:
> I was assuming if the variable starts with a #, it is a shared object,
> if not, it is a shell command:
>
> ssl_passphrase_command='#/lib/x.so'
> ssl_passphrase_command='my_command a b c'
Note that the proposed patch doesn't use a separate GUC -
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> >> I think it would be beneficial to explain why shared objec
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
On 11/14/19 11:07 AM, Bruce Momjian wrote:
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
I think it would be beneficial to explain why shared object is more
On 11/14/19 11:07 AM, Bruce Momjian wrote:
> On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
>> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
>> I think it would be beneficial to explain why shared object is more
>> secure than an OS command. Perhaps it's common knowledge
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
>
>
>
On Wed, Nov 13, 2019 at 3:23 PM Tomas Vondra
wrote:
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
External command args can be viewed by other OS users (not just the
postgres us
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
wrote:
> On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
> >On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> >
> >> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> >> > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus
On Wed, Nov 13, 2019 at 02:48:01PM -0500, Andrew Dunstan wrote:
On 11/13/19 8:08 AM, Bruce Momjian wrote:
Also, why was this patch posted without any discussion of these issues?
Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wr
On 11/13/19 8:08 AM, Bruce Momjian wrote:
>
>>
>> Also, why was this patch posted without any discussion of these issues?
>> Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
things without prior discussion. I would agree with your po
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
>
> > > One of the main reasons there being to be eas
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> > We had this
> > discussion in relation to archive_command years ago, and decided on a
> > shel
On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
> I don't recall that from back then, but th
On 11/7/19 12:30 PM, Andrew Dunstan wrote:
> On 11/4/19 4:43 PM, Thomas Munro wrote:
>> It looks like the new declarations in libpq-be.h are ifdef'd out in a
>> non-USE_SSL build, but then we still try to build the new test module
>> and it fails:
>>
>> https://ci.appveyor.com/project/postgresql-c
On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote:
> >
> > On 11/1/19 11:01 AM, Robert Haas wrote:
> > > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > > wrote:
> > >> This patch provides a hook for a function that can suppl
On Fri, Nov 08, 2019 at 11:12:08PM +0900, Simon Riggs wrote:
On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote:
What is the value of a shared library over a shell command? We had
this discussion in relation to archive_command years ago, and decided
on a shell command as the best API.
I don
On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote:
> What is the value of a shared library over a shell command? We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
I don't recall such a discussion, but I can give perspective:
On 11/4/19 4:43 PM, Thomas Munro wrote:
>
> It looks like the new declarations in libpq-be.h are ifdef'd out in a
> non-USE_SSL build, but then we still try to build the new test module
> and it fails:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.64071
I think this
On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote:
>
> On 11/1/19 11:01 AM, Robert Haas wrote:
> > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > wrote:
> >> This patch provides a hook for a function that can supply an SSL
> >> passphrase. The hook can be filled in by a shared p
On Sat, Nov 2, 2019 at 6:57 AM Andrew Dunstan
wrote:
> On 11/1/19 11:01 AM, Robert Haas wrote:
> > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > wrote:
> >> This patch provides a hook for a function that can supply an SSL
> >> passphrase. The hook can be filled in by a shared preloadable mo
On 11/1/19 11:01 AM, Robert Haas wrote:
> On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> wrote:
>> This patch provides a hook for a function that can supply an SSL
>> passphrase. The hook can be filled in by a shared preloadable module. In
>> order for that to be effective, the startup order
On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
wrote:
> This patch provides a hook for a function that can supply an SSL
> passphrase. The hook can be filled in by a shared preloadable module. In
> order for that to be effective, the startup order is modified slightly.
> There is a test attached
47 matches
Mail list logo
