Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> 1. Don't allow a CREATEROLE user to give out membership in groups
> which that user does not possess. Leaving aside the details of any
> previously-proposed patches and just speaking theoretically, how can
> this be implemented? I can think
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 2/25/22 12:39 PM, Tom Lane wrote:
> >Jeff Davis writes:
> >>On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
> >>>... and, since we can't readily enforce that the client only sends
> >>>those cleartext passwords over suitably-encr
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote:
> > I also have in mind here that there has been discussion of giving
> > libpq a feature to refuse, on the client side, to send cleartext
> > passwords.
>
> I am generally in favor of that ide
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> > Looks to me like authn_id isn't synchronized to parallel workers right now.
> > So
> > the function will return the wrong thing when executed as part of a parallel
> > qu
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > md5 should be removed.
>
> Really? I've always thought that the arguments against it were
> overblown for our use-case. At any rate, it's likely to be
> years before we could practical
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> David Steele writes:
> > Any thoughts on back-patching at least the client portion of this?
> > Probably hard to argue that it's a bug, but it is certainly painful.
>
> I'd be more eager to do that if we had some field complaints
> about it.
eration.
Thanks,
Stephen
From c8aff4ae7595647fb5c82ea2f726c2d5b866765c Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Mon, 28 Feb 2022 20:17:55 -0500
Subject: [PATCH] Add support for Kerberos credential delegation
Accept GSSAPI/Kerberos delegated credentials. With this, a user could
auth
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
> > Keeping it around will just push out the point at which everyone will
> > finally be done with it, as there's really only two groups: those who
>
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Feb 28, 2022 at 04:00:36PM -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> >> On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> >>> Looks to me like
Greetings,
* Antonin Houska (a...@cybertec.at) wrote:
> Here I'm starting a new thread to discuss a topic that's related to the
> Transparent Data Encryption (TDE), but could be useful even without that. The
> problem has been addressed somehow in the Cybertec TDE fork, and I can post
> the code
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Tue, Mar 01, 2022 at 08:44:51AM -0600, David Steele wrote:
> > Personally, I am in favor of removing it. We change/rename
> > functions/tables/views when we need to, and this happens in almost every
> > release.
> >
> > What we ne
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 3/1/22 11:32, Nathan Bossart wrote:
> >On Tue, Mar 01, 2022 at 11:09:13AM -0500, Chapman Flack wrote:
> >>On 03/01/22 09:44, David Steele wrote:
> >>>Personally, I am in favor of removing it. We change/rename
> >>>functions/tables/views w
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/01/22 13:22, David Steele wrote:
> > I think people are going to complain no matter what. If scripts are being
> > maintained changing the name is not a big deal (though moving from exclusive
> > to non-exclusive may be). If they ar
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/01/22 14:14, Stephen Frost wrote:
> >> There can't really be many teams out there thinking "we'll just ignore
> >> these scripts forever, and nothing bad will happen." They all know they&#
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote:
> > We already have a variety of authentication mechanisms that support central
> > management: LDAP, PAM, Kerberos, Radius.
>
> LDAP, PAM and Radius all require cleartext passwords, so
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 01.03.22 22:34, Andres Freund wrote:
> >The cases I've heard about are about centralizing auth across multiple cloud
> >services. Including secret management in some form. E.g. allowing an
> >application to auth to postg
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Mar 1, 2022 at 08:31:19AM -0500, Stephen Frost wrote:
> > > The last time I played with this area is the recent error handling
> > > improvement with cryptohashes but MD5 has actually helped here in
> > &
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> What is the logic to removing md5 but keeping 'password'?
>
> > I don't think we should keep 'password'.
>
> I
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:09:31AM -0500, Stephen Frost wrote:
> > I'm not sure that it's quite so simple. Perhaps we should also drop
> > LDAP and I don't really think PAM was ever terribly good for us to
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 02.03.22 15:16, Jonathan S. Katz wrote:
> >>I find that a lot of people are still purposely using md5. Removing it
> >>now or in a year would be quite a disruption.
> >
> >What are the reasons they are still purposely u
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:29:45AM -0500, Stephen Frost wrote:
> > We don't require SSL to be used with them..? Further, as already
> > discussed on this thread, SSL only helps with on-the-wire, doesn't
> > ad
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:54:27AM -0500, Stephen Frost wrote:
> > It's our decision what we want to support and maintain in the code base
> > and what we don't. Folks often ask for things that we don't or wo
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-02 09:32:26 +0100, Peter Eisentraut wrote:
> > On 01.03.22 22:34, Andres Freund wrote:
> > > The cases I've heard about are about centralizing auth across multiple
> > > cloud
> > > services. Including secret management in some f
Greetings,
* Pavel Borisov (pashkin.e...@gmail.com) wrote:
> > > BTW messages with patches in this thread are always invoke manual spam
> > moderation and we need to wait for ~3 hours before the message with patch
> > becomes visible in the hackers thread. Now when I've already answered
> > Alexan
Greetings,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > On 2/25/22 12:39 PM, Tom Lane wrote:
> >> Jeff Davis writes:
> >>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
> ... and, since we can't readily enforce that the client only sends
> those cleartext passwords over suitably-
Greetings,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > Yes, really, it's a known-broken system which suffers from such an old
> > and well known attack that it's been given a name: pass-the-hash. As
> > was discussed on this thread even, just the fact that it's not trivial
> > to break on the
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 02.03.22 21:49, samay sharma wrote:
> >I think we are discussing two topics in this thread which in my opinion
> >are orthogonal.
> >
> >(a) Should we make authentication methods pluggable by exposing these
> >hooks? - T
Greetings,
* Aleksander Alekseev (aleksan...@timescale.com) wrote:
> My last email to pgsql-jobs@ was moderated in a similar fashion. To my
> knowledge that mailing list is not pre-moderated. So it may have the same
> problem, and not only with patches. (We use regular Google Workspace.)
-jobs is
Greetings,
* Pavel Borisov (pashkin.e...@gmail.com) wrote:
> > On Thu, 3 Mar 2022 at 13:28, Pavel Borisov wrote:
> >> The mail system doesn't have the capability to apply different moderation
> >>> rules for people in that way I'm afraid.
> >>>
> >> Maybe then 2MB for everyone? Otherwise it's not
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > 1. What should be the exact rule for whether A can remove a grant made
> > by B? Is it has_privs_of_role()? is_member_of_role()? Something else?
>
> No strong opinion here, but I'd lean slightly to the more restrictive
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Mar 6, 2022 at 11:34 AM Tom Lane wrote:
> > I was thinking the former ... however, after a bit of experimentation
> > I see that we accept "grant foo to bar granted by baz" a VERY long
> > way back, but the "granted by" option for
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Agreed, this is not something to move on quickly. We might want
> >> to think about adjusting pg_dump to use explicit GRANTED BY
> >>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm not quite following this bit. Where would SET ROLE come into play
> > when we're talking about old dump scripts and how the commands in those
> > scripts might be interpreted by
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2022-03-02 at 10:54 -0500, Stephen Frost wrote:
> > It's our decision what we want to support and maintain in the code
> > base
> > and what we don't.
>
> That might be an argument in favor of cu
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/08/22 17:12, Nathan Bossart wrote:
> > I spent some time trying to come up with a workable script to replace the
> > existing one. I think the main problem is that you need to write out both
> > the backup label file and the tables
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/09/22 11:22, Magnus Hagander wrote:
> >> It's more than just too confusing, it's actively bad because people will
> >> actually use it and then end up with backups that don't work.
> >
> > +1.
> >
> > Or even worse, backups that s
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/09/22 12:19, Stephen Frost wrote:
> > Let's avoid hijacking [thread about other patch] [1]
> > for an independent debate about what our documentation should or
> > shouldn't include.
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
> > tgl> Having said that, one thing that I find fishy is that it's not clear
> > tgl> where the admin privilege for a role originates. After "CREATE ROLE
> > tgl> alice", al
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 9, 2022 at 4:01 PM Tom Lane wrote:
> > > In my opinion, the right to
> > > administer a role - regardless of whether or not it is a login role -
> > > most naturally vests in the role that created it, or something in that
> > >
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 7:46 AM Robert Haas wrote:
> > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > > I don't think we need syntax to describe it. As I just said in my
> > > other reply, we have a perfectly good preceden
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Thu, Mar 10, 2022 at 7:46 AM Robert Haas
> > wrote:
> > > > On
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> > > > * Da
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> But that's not to say that we couldn't decide to do something else
> instead, and that other thing might well be better. Do you want to
> sketch out a full proposal, even just what the syntax would look like,
> and share that here? And if y
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 2:58 PM Stephen Frost wrote:
> > It'd be useful to have a better definition of exactly what a
> > 'mini-superuser' is, but at least for the moment when it comes to roles,
> &
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 3:22 AM Jeff Davis wrote:
> > * Can we mark this extension 'trusted'? I'm not 100% clear on the
> > standards for that marker, but it seems reasonable for a database owner
> > with the right privileges might want to
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> > This seems reasonable in isolation, but
> >
> > (1) it implies a persistent relationship between creating and created
> > roles. Whether you want to call that ownership or not, it sure w
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 3:01 PM Robert Haas wrote:
>
> > On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> > wrote:
> > > I dislike changing the documented behavior of CREATEROLE to the degree
> > suggested here. However, t
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > If we implement the link between the creating role and the created
> > role as role ownership, then we are surely just going to add a
> > rolowner column to pg_authid, and when the role is owned by nobody, I
> > think we
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 11, 2022 at 11:12 AM Mark Dilger
> wrote:
> > This issue of how much backwards compatibility breakage we're willing to
> > tolerate is just as important as questions about how we would want roles to
> > work in a green-field
Greetings,
On Fri, Mar 11, 2022 at 12:32 Mark Dilger
wrote:
>
>
> > On Mar 11, 2022, at 8:48 AM, Stephen Frost wrote:
> >
> > I agree that it would have an impact on backwards compatibility to
> > change how WITH ADMIN works- but it would also get us more in line
Greetings,
On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote:
> On Mon, 2022-02-28 at 20:28 -0500, Stephen Frost wrote:
> > Will add to the CF for consideration.
>
> GSSAPI newbie here, so caveat lector.
No worries, thanks for your interest!
> diff --git a/src/backend/
Greetings,
On Fri, Mar 11, 2022 at 19:03 Mark Dilger
wrote:
> > On Mar 11, 2022, at 2:46 PM, Stephen Frost wrote:
> >
> > I do think that’s reasonable … and believe I suggested it about 3
> messages ago in this thread. ;) (step #3 I think it was? Or maybe 4).
>
> Y
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Mar 11, 2022, at 4:56 PM, Stephen Frost wrote:
> > First … I outlined a fair bit of further description in the message you
> > just responded to but neglected to include in your response, which strikes
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Thu, 2022-03-10 at 15:54 -0500, Stephen Frost wrote:
> > The standard is basically that all of the functions it brings are
> > written to enforce the PG privilege system and you aren't able to use
> > the extension
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Tue, Mar 15, 2022 at 7:21 AM Bharath Rupireddy
> wrote:
> >
> > On Mon, Mar 14, 2022 at 8:25 PM Stephen Frost wrote:
> > >
> > > > As this patch is current
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Fri, Mar 4, 2022 at 11:15 AM Jacob Champion wrote:
> > On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> > > At the moment, it is not possible to judge whether the hook interface
> > > you have chosen is appropriate.
> > >
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2022-03-16 at 11:02 -0400, Stephen Frost wrote:
> > That we're having to extend this quite a bit to work for the proposed
> > OAUTH patches and that it still doesn't do anything for the client
> > side
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Wed, Mar 16, 2022 at 8:02 AM Stephen Frost wrote:
> > How about- if we just added OAUTH support directly into libpq and the
> > backend, would that work with Azure's OIDC provider? If not, why not?
>
> Ov
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > Looking at the existing authentication methods
> >
> > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> > # "gss", "sspi", "ident", "peer", "pam", "ldap", "ra
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > > Looking at the existing authentication met
Greetings,
On Thu, Mar 17, 2022 at 17:02 Andres Freund wrote:
> On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> > First, let's be clear- we aren't actually talking about custom or
> > pluggable authentication here, at least when it comes to PG as a
> >
Greetings,
On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> On 2022-03-17 22:13:27 -0400, Stephen Frost wrote:
> > This isn’t the first time I asked about this on this thread, yet the
> > question about why this is only being discussed as backend changes, and
> > with
Greetings,
On Fri, Mar 18, 2022 at 00:24 Andres Freund wrote:
> Hi,
>
> On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> > On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > > It's imo a separate project to make the client side extensible. There's
&g
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > > I also don’t think that I agree that it’s acceptable to only have the
> > > > ability to extend the authentication on the server side as that implies
> >
Greetings,
On Sun, Mar 20, 2022 at 18:31 Joshua Brindle
wrote:
> On Sun, Mar 20, 2022 at 12:27 PM Joe Conway wrote:
> >
> > On 3/3/22 11:26, Joshua Brindle wrote:
> > > On Thu, Feb 10, 2022 at 2:37 PM Joe Conway wrote:
> > >>
> > >> On 2/10/22 14:28, Nathan Bossart wrote:
> > >> > On Wed, Feb
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> While reading about deprecating and removing various things in other
> threads, I was wondering about how deprecated SELECT INTO is. There are
> various source code comments about this, but the SELECT INTO reference page
>
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * vignesh C (vignes...@gmail.com) wrote:
> > Thanks for testing this, I had missed testing this. The expression
> > matching was not correct. Attached v6 patch which includes the fix for
> > this.
>
> This genera
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian wrote:
> > The downside is you end up with X-1 dummy sections just to allow for
> > references to old syntax, and you then have to find them all and remove
> > them when you impleme
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Dec 2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian wrote:
> > > > The downside is you
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> On Thu, Nov 19, 2020 at 10:00 AM Stephen Frost wrote:
> > * Thomas Munro (thomas.mu...@gmail.com) wrote:
> > > Hmm. Every time I try to think of a protocol change for the
> > > restore_command API that would
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Dec 2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> > On Wed, 2 Dec 2020 at 19:33, David G. Johnston
> > wrote:
> >
> > On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote:
> >
> > I think the ideal solution is to c
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-12-04 13:27:38 -0500, Stephen Frost wrote:
> > If I follow correctly, this patch will scan ahead in the WAL and let
> > the kernel know that certain blocks will be needed soon. Ideally,
> > though I don'
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost wrote:
> > Obviously, I'd then have to adjust the patch that I proposed for default
> > roles, or move forward with it as-is, depending on what we end up doing
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> I think starting a spread checkpoint has some usefulness, if your
> checkpoint interval is very large but your completion target is not very
> close to 1. In that case, you're expressing that you want a checkpoint
> to start now and n
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> This all seems reasonable to me. I've attached a new version of the
> patch.
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 2afee6d7b5..2b1e56fbd7 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> Thanks. I'll do some testing/benchmarking once my machines are free, in
> a couple days perhaps. But as I said before, I don't expect this to
> behave very differently from other places that already do prefetching.
Agreed, but wou
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 12/5/20, 6:41 AM, "Stephen Frost" wrote:
> > Assuming we actually want to do this, which I still generally don't
> > agree with since it isn't really clear if it'll actually end up doing
>
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2020-Dec-05, Stephen Frost wrote:
> > So- just to be clear, CHECKPOINTs are more-or-less always happening in
> > PG, and running this command might do something or might end up doing
> > nothing depending
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Dec 06, 2020 at 10:03:08AM -0500, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> >> You keep making this statement, and I don't necessarily disagree, but if
> >> that
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 2020-12-07 18:53, Stephen Frost wrote:
> >* Michael Paquier (mich...@paquier.xyz) wrote:
> >>On Sun, Dec 06, 2020 at 10:03:08AM -0500, Stephen Frost wrote:
> >>>* Alvaro Herrera (
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 2 Dec 2020, at 22:38, Bruce Momjian wrote:
> > Attached is a patch for key management, which will eventually be part of
> > cluster file encryption (CFE), called TDE (Transparent Data Encryption)
> > by Oracle.
>
> The attackvector p
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Tue, 2020-12-08 at 17:29 +, Bossart, Nathan wrote:
> > +1 to setting checkpoint_completion_target to 0.9 by default.
>
> +1 for changing the default or getting rid of it, as Tom suggested.
Attached is a patch to change it from
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2020-Dec-10, Stephen Frost wrote:
> > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > On Tue, 2020-12-08 at 17:29 +, Bossart, Nathan wrote:
> > > > +1 to setting checkpoint_compl
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > On 2020-Oct-29, Stephen Frost wrote:
> >> I do think it'd be good to find a way to check every once in a while
> >> even when we aren't going to delay though. Not sure what the be
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Dec 15, 2020 at 10:05:49AM +0900, Michael Paquier wrote:
> > On Mon, Dec 14, 2020 at 06:06:15PM -0500, Bruce Momjian wrote:
> > > I am getting close to applying these patches, probably this week. The
> > > patches are cumulative:
> >
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Dec 15, 2020 at 02:09:09PM -0500, Stephen Frost wrote:
> > Yeah, looking at what's been done there seems like the right approach to
> > me as well, ideally we'd have one set of APIs that'll suppor
Greetings,
* Alastair Turner (min...@decodable.me) wrote:
> On Wed, 16 Dec 2020 at 00:12, Bruce Momjian wrote:
> > The second approach is to make a new API for what you want
>
> I am trying to motivate for an alternate API. Specifically, an API
> which allows any potential adopter of Postgre
Greetings,
* Alastair Turner (min...@decodable.me) wrote:
> On Wed, 16 Dec 2020 at 21:32, Stephen Frost wrote:
> > * Alastair Turner (min...@decodable.me) wrote:
> > > On Wed, 16 Dec 2020 at 00:12, Bruce Momjian wrote:
> > > > The second approach is to ma
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, Dec 16, 2020 at 05:04:12PM -0500, Bruce Momjian wrote:
> >> fallback implementation. Finally, pgcrypto is not touched, but we
> >
> > I have a fallback implemention --- it fails? ;-) Did you want me to
> > include an AES imple
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote:
> > Agreed. I think there is serious risk we would do AES in a different
> > way than OpenSSL, especially if I did it. ;-) We can add a native AES
> > one day if we want, b
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Dec 18, 2020 at 10:01:22AM +0900, Michael Paquier wrote:
> > On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote:
> > > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote:
> > >> I do
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Dec 18, 2020 at 08:18:53AM -0500, Stephen Frost wrote:
> > - C API in backend - we should try to at least set up the structure to
> > allow multiple encryption implementations, either via different
> > li
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 18/12/2020 05:57, Michael Paquier wrote:
> >As mentioned in [1], there are three places where there is the same
> >routine to check if a string is made only of ASCII characters.
> >
> >This makes for a small-ish but nice cleanup, as per
Greetings Alastair,
* Alastair Turner (min...@decodable.me) wrote:
> On Wed, 16 Dec 2020 at 22:43, Stephen Frost wrote:
> > If I'm following, you're suggesting something like:
> >
> > cluster_passphrase_command = 'aws get %q'
> >
> > and the
Greetings Alastair,
* Alastair Turner (min...@decodable.me) wrote:
> On Sat, 19 Dec 2020 at 16:58, Bruce Momjian wrote:
> > To enable the direct injection of keys into the server, we would need a
> > new command for this, since trying to make the passphrase command do
> > this will lead to unnece
Greetings,
* Alastair Turner (min...@decodable.me) wrote:
> On Sun, 20 Dec 2020 at 22:59, Stephen Frost wrote:
> > Yes, it's true that after things are implemented it can be more
> > difficult to change them- but if you're concerned about the specific
> > on-
Greetings,
* Alastair Turner (min...@decodable.me) wrote:
> On Mon, 21 Dec 2020 at 00:33, Stephen Frost wrote:
> > * Alastair Turner (min...@decodable.me) wrote:
> > > What I'd like specifically is to have the option of an external
> > > keyring as a first class
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Jeff Janes writes:
> > On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost wrote:
> >> * Magnus Hagander (mag...@hagander.net) wrote:
> >>> Maybe we should do the same for LDAP (and RADIUS)? This seems like a
> >&
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Jeff Janes writes:
> >>> I would suggest going further. I would make the change on the client
> >>> side,
> >>> an
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Dec 21, 2020 at 7:44 PM Tom Lane wrote:
> > BTW, do we have a client-side setting to insist that passwords not be
> > sent in MD5 hashing either? A person who is paranoid about this would
> > likely want to disable that code pat
1 - 100 of 1955 matches
Mail list logo
