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,
* 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 li
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
> &g
7595647fb5c82ea2f726c2d5b866765c 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
authenticate to PostgreSQL using Kerberos cr
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.
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 practically do that
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
> >
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
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
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
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> I am writing done above in quotes, since the documentation also needs to be
> updated, completed, rewritten, organized etc etc. The above is an import of
> what was found, and is in a fairly poor state. Unfortunately, it's still not
> in
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> > As a philosophical matter, I don't think it's great for us - or the
> > Internet in general - to be too dependent on OpenSSL. Software
> > monocultures are not great, and
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > > > There's https://hg.mozilla
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 3 Feb 2022, at 15:07, Peter Eisentraut
> > wrote:
> >
> > On 28.01.22 15:30, Robert Haas wrote:
> >> I would really, really like to have an alternative to OpenSSL for PG.
> >
> > What are the reasons people want that? With
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > think the upstream source.
> >
> > A project without even a bare-minimal README at the root does
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 31, 2022, at 10:50 AM, Stephen Frost wrote:
> > Supporting that through ADMIN is one option, another would be a
> > 'DROPROLE' attribute, though we'd want a way to curtail that from being
> > able
Greetings,
* Fujii Masao (masao.fu...@oss.nttdata.com) wrote:
> On 2022/02/01 22:03, Bharath Rupireddy wrote:
> >On Tue, Feb 1, 2022 at 11:58 AM Kyotaro Horiguchi
> > wrote:
> >>>Modified in v8.
> >>
> >>0001 looks good to me.
>
> I found that CreateRestartPoint() already reported the redo lsn
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 31 Jan 2022, at 22:48, Daniel Gustafsson wrote:
> >> On 31 Jan 2022, at 17:24, Stephen Frost wrote:
>
> >> I agree that it's concerning to hear that OpenLDAP dropped support for
> >> NSS... th
Greetings,
On Tue, Feb 1, 2022 at 12:50 Bruce Momjian wrote:
> On Tue, Feb 1, 2022 at 07:45:06AM +0100, Antonin Houska wrote:
> > > With pg_upgrade modified to preserve the relfilenode, tablespace oid,
> and
> > > database oid, we are now closer to implementing cluster file encryption
> > >
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 31, 2022, at 8:53 AM, Stephen Frost wrote:
> > Yeah, we do need to have a way to determine who is allowed to drop
> > roles and role ownership seems like it's one possible approach to that.
>
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
> > I agree that CREATEROLE is overpowered and that the goal of this should
> > be to provide a way for roles to be created and dropped that doesn't
> &g
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 28 Jan 2022, at 15:30, Robert Haas wrote:
> > On Fri, Jan 28, 2022 at 9:08 AM Daniel Gustafsson wrote:
> >>> Kinda makes me question the wisdom of starting to depend on NSS. When
> >>> openssl
> >>> docs are vastly outshining a
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Fri, Jan 28, 2022 at 11:16 AM Nathan Bossart
> wrote:
> > I know I voted for "start=%X/%X, end=%X/%X," but looking at this again, I
> > wonder if it could be misleading. "start" is the redo location, and "end"
>
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
> > Being able to create and drop users is, in fact, effectively a
> > superuser-only task today. We could throw out the entire idea of role
> > owne
Greetings,
On Mon, Jan 24, 2022 at 16:42 Robert Haas wrote:
> On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost wrote:
> > The idea behind this patch is to enable creation and dropping of roles,
> which isn’t possible now without being effectively a superuser.
> >
> >
Greetings,
On Mon, Jan 24, 2022 at 15:33 Robert Haas wrote:
> On Sat, Jan 22, 2022 at 4:20 PM Stephen Frost wrote:
> > Whoah, really? No, I don't agree with this, it's throwing away the
> > entire concept around inheritance of role rights and how you can have
> > ro
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 4, 2022, at 12:47 PM, Joshua Brindle
> > wrote:
> >
> >> I was able to reproduce that using REASSIGN OWNED BY to cause a user to
> >> own itself. Is that how you did it, or is there yet another way to get
> >> into
Greetings,
* vrund shah (vrund3...@gmail.com) wrote:
> Thank you for your valuable guidance.
> I will surely look at the links and if have any queries then I will contact
> you.
On these mailing lists, we prefer that you reply 'in-line', as I'm doing
here, and not use 'top-posting' (as you did
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 1/21/22 21:28, Stephen Frost wrote:
> >* vrund v shah (vrund3...@gmail.com) wrote:
> >>I am Vrund V Shah, a computer science undergrad. I have just completed
> >> my
> >>
Greetings,
* vrund v shah (vrund3...@gmail.com) wrote:
>I am Vrund V Shah, a computer science undergrad. I have just completed my
>3^rd semester at G H Patel College of Engineering & Technology. I am new
>to open source contribution but I am well aware of C/C++, SQL and I will
>
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Tue, 2022-01-04 at 22:24 -0500, Stephen Frost wrote:
> > On Tue, Jan 4, 2022 at 18:56 Jacob Champion wrote:
> > >
> > > Could you talk more about the use cases for which having the "actual
> &g
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 5, 2022 at 9:53 PM Alexander Korotkov
> wrote:
> > 5) 32-bit limitation within the page mentioned upthread by Stephen
> > Frost should be also carefully considered. Ideally, we should get rid
> >
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jan 7, 2022 at 03:56:39PM -0500, Stephen Frost wrote:
> > As for the details of how we allow control over it, I suppose there's a
> > number of options. Having it in the HBA doesn't seem terrible, though I
> > s
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> On Fri, Jan 07, 2022 at 01:46:00PM -0500, Bruce Momjian wrote:
> > On Sat, Jan 1, 2022 at 11:25:05AM -0600, Justin Pryzby wrote:
> > > Thanks for working on this. The patch looks to be in good shape - I hope
> > > more
> > > people
Greetings,
On Tue, Jan 4, 2022 at 18:56 Jacob Champion wrote:
> On Mon, 2022-01-03 at 19:42 -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > >
> > > That last point was my motivation for the authn_id patch [1] -- so that
> > >
Greetings,
* Maxim Orlov (orlo...@gmail.com) wrote:
> Long time wraparound was a really big pain for highly loaded systems. One
> source of performance degradation is the need to vacuum before every
> wraparound.
> And there were several proposals to make XIDs 64-bit like [1], [2], [3] and
> [4]
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Mon, 2022-01-03 at 12:36 -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > > On Fri, 2021-12-17 at 10:06 +0100, Peter Eisentraut wrote:
> > > > On 17.12.21 00:48, Jacob
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Fri, 2021-12-17 at 10:06 +0100, Peter Eisentraut wrote:
> > On 17.12.21 00:48, Jacob Champion wrote:
> > > WDYT? (My responses here will be slower than usual. Hope you all have a
> > > great end to the year!)
> >
> > Looks
Greetings,
On Wed, Dec 29, 2021 at 14:04 SATYANARAYANA NARLAPURAM <
satyanarlapu...@gmail.com> wrote:
> Stephen, thank you!
>
> On Wed, Dec 29, 2021 at 5:46 AM Stephen Frost wrote:
>
>> Greetings,
>>
>> * SATYANARAYANA NARLAPURAM (satyanarlapu...@gmail.com) w
Greetings,
* Euler Taveira (eu...@eulerto.com) wrote:
> On Thu, Dec 23, 2021, at 9:58 AM, Bharath Rupireddy wrote:
> > pg_archivecleanup currently takes a WAL file name as input to delete
> > the WAL files prior to it [1]. As suggested by Satya (cc-ed) in
> > pg_replslotdata thread [2], can we
Greetings,
* SATYANARAYANA NARLAPURAM (satyanarlapu...@gmail.com) wrote:
> On Sat, Dec 25, 2021 at 9:25 PM Dilip Kumar wrote:
> > On Sun, Dec 26, 2021 at 10:36 AM SATYANARAYANA NARLAPURAM <
> > satyanarlapu...@gmail.com> wrote:
> >>> Actually all the WAL insertions are done under a critical
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Fri, 2021-12-10 at 10:20 -0500, Tom Lane wrote:
> > Jeff Janes writes:
> > > Can we change the default setting of track_io_timing to on?
> >
> > That adds a very significant amount of overhead on some platforms
> > (gettimeofday
Greetings,
On Tue, Nov 30, 2021 at 11:47 Laurenz Albe wrote:
> On Tue, 2021-11-30 at 09:20 -0500, Stephen Frost wrote:
> > Greetings,
> >
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Michael Paquier writes:
> > > > On Thu, Nov 25, 2021 at 06:19:03
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Thu, Nov 25, 2021 at 06:19:03PM -0800, SATYANARAYANA NARLAPURAM wrote:
> >> If we are keeping it then why not make it better?
>
> > Well, non-exclusive backups are better by design in many aspects, so I
> > don't
Greetings,
On Tue, Nov 16, 2021 at 15:12 Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Nov-16, Stephen Frost wrote:
> >> Not against possibly changing that but I don’t get the point of
> including
> >> be-gssapi-common.h if it’s not enabled in the b
Greetings,
On Tue, Nov 16, 2021 at 13:16 Alvaro Herrera
wrote:
> On 2021-Nov-16, Stephen Frost wrote:
>
> > Not against possibly changing that but I don’t get the point of including
> > be-gssapi-common.h if it’s not enabled in the build and typically if
> GSSAPI
> >
Greetings,
On Tue, Nov 16, 2021 at 12:33 Alvaro Herrera
wrote:
> On 2021-Nov-16, Stephen Frost wrote:
>
> > Short answer is yes, inclusion of be-gssapi-common.h is typically
> > wrapped in a #ifdef, see src/backend/libpq/auth.c
>
> It'd be as in the attached,
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-16, Alvaro Herrera wrote:
>
> > Fix headerscheck failure in replication/worker_internal.h
>
> The other failure is in src/include/libpq/be-gssapi-common.h:
>
> In file included from /tmp/headerscheck.a6f0um/test.c:2:
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Nov 15, 2021 at 2:51 PM Stephen Frost wrote:
> > I get that just compressing the entire stream is simpler and easier and
> > such, but it's surely cheaper and more efficient to not decompress and
> > then r
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 15 Nov 2021, at 15:32, Robert Haas wrote:
> > On Tue, Nov 9, 2021 at 9:12 AM Daniel Gustafsson wrote:
> >> 2773: libpq compression
> >> ===
> >> This patch intended to provide libpq connection compression to
Greetings,
* Andrey Borodin (x4...@yandex-team.ru) wrote:
> > On 11/10/21 16:54, Andrey Borodin wrote:
> >> Compression is crucial for highly available setups. Replication traffic is
> >> often billed. Or route has bandwidth limits.
> >> An entropy added by WAL headers makes CRIME attack against
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Daniel Gustafsson writes:
> > 2773: libpq compression
> > ===
> > This patch intended to provide libpq connection compression to "replace SSL
> > compression" which was doomed when the patch was written, and have since
> >
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 9, 2021, at 8:22 AM, Stephen Frost wrote:
> > In terms of least-surprise, I do tend to think that the answer is "only
> > care about what is explicitly put into the command"- that is, if it
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Mon, 2021-11-08 at 12:47 -0500, Stephen Frost wrote:
> >
> > I don't feel as strongly as others apparently do on this point
> > though,
> > and I'd rather have non-superusers able to run CHECKPOINT *somehow*
>
Greetings,
* David Christensen (david.christen...@crunchydata.com) wrote:
> On Tue, Nov 9, 2021 at 9:55 AM Mark Dilger
> wrote:
> > > On Nov 9, 2021, at 7:36 AM, David Christensen <
> > david.christen...@crunchydata.com> wrote:
> > > If CINE semantics are at issue, what about the CREATE OR
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 9, 2021, at 7:36 AM, David Christensen
> > wrote:
> > If CINE semantics are at issue, what about the CREATE OR REPLACE semantics
> > with some sort of merge into the existing role? I don't care strongly
> > about which
Greetings,
* David Christensen (david.christen...@crunchydata.com) wrote:
> On Mon, Nov 8, 2021 at 1:22 PM Mark Dilger
> wrote:
>
> > > On Nov 8, 2021, at 10:38 AM, Stephen Frost wrote:
> >
> > > I don't quite follow this. The entire point of Alice
Greetings,
* Joshua Brindle (joshua.brin...@crunchydata.com) wrote:
> On Wed, Oct 27, 2021 at 5:20 PM Joshua Brindle
> wrote:
> > On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
> > > On Wed, Oct 27, 2021 at 5:14 PM Joshua Brindle
> > > wrote:
> > > > Attached is an updated version of the
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Wed, 2021-10-27 at 12:53 -0400, Jonathan S. Katz wrote:
> > The patch I propose just layers on top of the existing functionality --
> > you could even argue that it's "fixing a bug" that we did not add the
> > current "map"
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Tue, 2 Nov 2021 at 19:00, Vik Fearing wrote:
> > On 11/2/21 11:14 PM, Vik Fearing wrote:
> >
> > > This would be nice, but there is nothing to hang our hat on:
> > >
> > > GRANT CHECKPOINT TO username;
> >
> > Thinking about
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> I noticed recently that permissions checking is done differently for the
> server certificate key than the client key. Specifically, on the server the
> key can have 640 perms if it is owned by root.
Yeah, that strikes me as odd too,
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 3 Nov 2021, at 23:18, Tom Lane wrote:
> > I'm generally pretty down on IF NOT EXISTS semantics in all cases,
> > but it seems particularly dangerous for something as fundamental
> > to privilege checks as a role. It's not hard at
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-08, Stephen Frost wrote:
>
> > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
>
> > > That said, if the list is short, then additional predefined roles seem
> > > preferrable to ha
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-08 12:23:18 -0500, Stephen Frost wrote:
> > though I continue to feel like the function based approach is better.
>
> I think it's a somewhat ugly hack.
I suppose we'll just have to disagree on that. :
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-04, Jeff Davis wrote:
> > But I don't see it generalizing to a lot of commands, either. I looked
> > at the list, and it's taking some creativity to think of more than a
> > couple other commands where it makes sense.
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-05 08:54:37 -0400, Robert Haas wrote:
> > On Thu, Nov 4, 2021 at 6:46 PM Andres Freund wrote:
> > > What about extending GRANT to allow to grant rights on commands? Yes,
> > > it'd be
> > > a bit of work to make that work in
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-05 08:42:58 -0400, Robert Haas wrote:
> > On Thu, Nov 4, 2021 at 7:38 PM Jeff Davis wrote:
> > > It seems like this specific approach has been mostly shot down already.
> > > But out of curiosity, are you intending to run
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 11/2/21, 11:27 AM, "Stephen Frost" wrote:
> > * Bossart, Nathan (bossa...@amazon.com) wrote:
> >> The approach in the patch looks alright to me, but another one could
> >> be to build a SelectS
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Nov 1, 2021 at 02:24:36PM -0400, Stephen Frost wrote:
> > I can understand the general idea that we should be sure to engineer
> > this in a way that multiple methods can be used, as surely one day folks
> >
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Tue, 2021-11-02 at 11:06 -0400, Robert Haas wrote:
> > Just as a sort of general comment on this endeavor, I suspect that
> > any
> > attempt to lump things together that seem closely related is doomed
> > to
> > backfire.
>
> Agreed, I
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 1, 2021, at 1:13 PM, Stephen Frost wrote:
> >> Having Batman *own* all residents in Gotham city would work, if we can
> >> agree on a role ownership system. It has the downside that onl
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 1, 2021, at 12:44 PM, Stephen Frost wrote:
> > I can generally get behind the idea that a user who has been allowed to
> > create other roles should be able to do various other things with that
> &g
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 25, 2021, at 11:30 AM, Stephen Frost wrote:
>
> > Consider instead:
> >
> > CREATE ROLE X;
> > CREATE ROLE Y;
> > CREATE ROLE Z;
> >
> > GRANT Y to X;
> > GR
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 29, 2021, at 4:46 PM, Jeff Davis wrote:
> > But I don't think the concept of role ownership has zero potential
> > confusion, either. For instance, I could certainly imagine a user A
> > creating a role B (and therefore
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 26, 2021 at 11:11:39PM +0200, Tomas Vondra wrote:
> > BTW I'm not sure what the existing patches do, but I wonder if we should
> > calculate the checksum before or after encryption. I'd say it should be
> > after encryption,
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/25/21, 1:41 PM, "Bossart, Nathan" wrote:
> > Great. Unless I see additional feedback on the basic design shortly,
> > I'll give the documentation updates a try.
>
> Okay, here is a more complete patch with a first attempt at the
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 11/1/21, 9:51 AM, "Stephen Frost" wrote:
> > All that said, I wonder if we can have our cake and eat it too. I
> > haven't looked into this at all yet and perhaps it's foolish on its
> > face
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/30/21, 11:14 AM, "Jeff Davis" wrote:
> > On Sat, 2021-10-30 at 13:24 +0530, Bharath Rupireddy wrote:
> >> IMHO, moving away from SQL command "CHECKPOINT" to function
> >> "pg_checkpoint()" isn't nice as the SQL command has been
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Tue, 2021-10-26 at 00:07 +, Bossart, Nathan wrote:
> > It feels a bit excessive to introduce a new predefined role just for
> > this. Perhaps this could be accomplished with a new function that
> > could be granted.
>
> It would be
Greetings,
* Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет:
> > * Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> > > В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > > > I really don't thi
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost wrote:
> > > Exactly. That's the main point. Also, it's currently a best practice for
> > > only non-LOGIN roles to have members. The proposed approach
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Independent of other things, getting to the point where everything can
> > be done in the database without the need for superuser is absolutely a
> > good goal to be striving for, not something
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Sun, 2021-10-24 at 21:32 +, Bossart, Nathan wrote:
> > My initial reaction was that members of pg_maintenance should be able
> > to do all of these things (VACUUM, ANALYZE, CLUSTER, REINDEX, and
> > CHECKPOINT).
>
> What about REFRESH
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Sun, Oct 24, 2021 at 3:15 AM Jeff Davis wrote:
> > Add new predefined role pg_maintenance, which can issue VACUUM,
> > ANALYZE, CHECKPOINT.
> >
> > Patch attached.
>
> At this point, the idea of having a new
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Oct 21, 2021 at 11:05 PM Robert Haas wrote:
> > On Thu, Oct 21, 2021 at 4:29 PM Stephen Frost wrote:
> > > restore_command used to be in recovery.conf, which disappeared with v12
> >
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Oct 20, 2021 at 11:27:11AM -0700, Jeff Davis wrote:
> > On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
> > > I'd like to have a much clearer understanding of Noah's complaint
> > > first. There are multiple things to consider:
Greetings,
* Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > I really don't think this is necessary. Similar to PageSetChecksumCopy
> > and PageSetChecksumInplace, I'm sure we would have functions which are
> > call
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 19, 2021 at 02:54:56PM -0400, Stephen Frost wrote:
> > * Sasasu (i...@sasa.su) wrote:
> > > A unified block-based I/O API sounds great. Has anyone tried to do this
> > > before? It would be nice if the
Greetings,
* Sasasu (i...@sasa.su) wrote:
> On 2021/10/22 01:28, Stephen Frost wrote:
> >None of these are actually working with or changing the data though,
> >they're just copying it. I don't think we'd actually want these to
> >decrypt and reencrypt the data.
>
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 19, 2021 at 2:50 PM Stephen Frost wrote:
> > I keep seeing this thrown around and I don't quite get why we feel this
> > is the case. I'm not completely against trying to maintain backwards
> > compatibi
Greetings,
* Sasasu (i...@sasa.su) wrote:
> On 2021/10/20 20:24, Stephen Frost wrote:
> > PG does have a block-based IO API, it's just not exposed as hooks. In
> > particular, take a look at md.c, though perhaps you'd be more interested
> > in the higher le
Greetings,
On Wed, Oct 20, 2021 at 16:23 Robert Haas wrote:
> On Wed, Oct 20, 2021 at 1:20 PM Jeff Davis wrote:
> > A downside is that with my suggestion, event triggers would still be
> > for the highly-privileged roles only. Allowing unprivileged users to
> > create event triggers that have
PG community.
We'd certainly welcome them. I don't think we're going to try to
redesign our entire IO subsystem in the hopes that they'll show up
though.
> On 2021/10/20 02:54, Stephen Frost wrote:
> > Where would you store the tag for GCM without changes in core?
>
> If can add
Greetings,
On Tue, Oct 19, 2021 at 18:26 Mark Dilger
wrote:
>
>
> > On Oct 19, 2021, at 3:18 PM, Jeff Davis wrote:
> >
> > On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
> >> Wouldn't it be much cleaner to have superuser bypass the trigger?
> >
> > Maybe it could be a user property like
Greetings,
* Sasasu (i...@sasa.su) wrote:
> On 2021/10/19 00:37, Robert Haas wrote:
> >I think what we ought to be doing at
> >this point is combining our efforts to try to get some things
> >committed which make future work in this area committed - like that
> >patch to preserve relfilenode and
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> Backwards compatibility is definitely a must, I'd say. Regardless of
> exactly how the backwards-compatible pugin is shipped, it should be what's
> turned on by default.
I keep seeing this thrown around and I don't quite get why we feel
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 10/18/21 17:56, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> >>On 10/15/21 21:22, Stephen Frost wrote:
> >>>Now, to address the concern around re-encrypting a b
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 10/15/21 21:22, Stephen Frost wrote:
> >Now, to address the concern around re-encrypting a block with the same
> >key+IV but different data and leaking what parts of the page changed, I
> >do think
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 10/15/21 17:05, Alexander Pyhalov wrote:
> >Tomas Vondra писал 2021-10-15 17:56:
> >>And then we should extend this for aggregates with more complex
> >>internal states (e.g. avg), by supporting a function that "exports"
>
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> As you might have seen from my email in another thread, thanks to
> Stephen and Cybertec staff, I am back working on cluster file
> encryption/TDE.
>
> Stephen was going to research if XTS cipher mode would be a good fit for
> this since it
301 - 400 of 1906 matches
Mail list logo
