Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> > I'm sure there's a lot of folks who'd like to see more of the logic we
> > have in pg_dump for building objects from the catalog available to more
> > tools through libpgcommon- psql being one of the absolute first
> > use-cases for e
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Mon, Aug 24, 2020 at 6:38 AM John Naylor
> wrote:
> > Other ideas?
>
> I've been experimenting with changing the way that we enforce heap
> fill factor with calls to heap_insert() (and even heap_update()) that
> happen to occur at a "natur
Greetings,
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> I have run some benchmarks for this patch. Overall it seems that there is a
> good improvement with the patch on recovery times:
Maybe I missed it somewhere, but what's the OS/filesystem being used
here..? What's the filesyst
Greetings,
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> OS version is Ubuntu 18.04.5 LTS.
> Filesystem is ext4 and block size is 4KB.
[...]
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> I have run some benchmarks for this patch. Overall it seems that there is a
> good
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On August 27, 2020 11:26:42 AM PDT, Stephen Frost wrote:
> >Is WAL FPW compression enabled..? I'm trying to figure out how, given
> >what's been shared here, that replaying 25GB of WAL is being helped out
> &g
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost wrote:
> > > Hm? At least earlier versions didn't do prefetching for records with an
> > > fpw, and only for subsequent records affecting the same or if not in s_b
Greetings,
There's no shortage of requests and responses regarding how to have a
'read all of the data' role in PG, with various hacks involving "GRANT
ALL" and "ALTER DEFAULT PRIVILEGES" to "solve" this, neither of which
really works long term ("GRANT ALL" is one-time, and "ALTER DEFAULT"
only he
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> Without having actually looked at the code, definite +1 for this feature.
> It's much requested...
Thanks.
> But, should we also have a pg_write_all_data to go along with it?
Perhaps, but could certainly be a different patch, and it'd
Greetings,
* Georgios Kokolatos (gkokola...@protonmail.com) wrote:
> The patch seems to be implementing a useful and requested feature.
> The patch applies cleanly and passes the basic regress tests. Also the
> commitfest bot is happy.
>
> A first pass at the code, has not revealed any worthwhil
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 28 Aug 2020 at 08:43, Stephen Frost wrote:
> > This would simply REVOKE that role from the user. Privileges
> > independently GRANT'd directly to the user wouldn't be affected. Nor
> &
Greetings,
* gkokola...@pm.me (gkokola...@pm.me) wrote:
> On Friday, 28 August 2020 15:43, Stephen Frost wrote:
> > > What privileges would the user be left with? Would it be possible to end
> > > up in the same privilege only with a GRANT command?
> >
> > I&#
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > Without having actually looked at the code, definite +1 for this feature.
> > > It's
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
> Le 28/08/2020 à 15:26, Stephen Frost a écrit :
> >* Magnus Hagander (mag...@hagander.net) wrote:
> >>On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> >>>* Magnus Hagander (mag...@hagander.net) wrote:
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
> Le 28/08/2020 à 16:52, Stephen Frost a écrit :
> >Using an FDW will often also require having a user mapping and there's
> >no way for that to be accomplished through only GRANT'ing a default
> >role, so I
Greetings,
* Andrey Lepikhov (a.lepik...@postgrespro.ru) wrote:
> During the implementation of sharding related improvements i noticed that if
> we use a lot of foreign partitions, we have bad plans because of vacuum
> don't update statistics of foreign tables.This is done by the ANALYZE
> command
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Aug 27, 2020 at 04:28:54PM -0400, Stephen Frost wrote:
> >* Robert Haas (robertmh...@gmail.com) wrote:
> >>On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost wrote:
> >>> > Hm? At least earli
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> > > * Magnus Hagander (mag...@hagander.net) wrote:
> > > > Without having actually looked at
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sat, Aug 29, 2020 at 12:50:59PM -0400, Tom Lane wrote:
> > Stephen Frost writes:
> > > Isn't this going to create a version dependency that we'll need to deal
> > > with..? What if a newer major vers
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > I don't think there was enough value to do statistics migration just for
> > > pg_upgrade, but
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote:
> > The point I was making was that it has value and people did realize it
> > but there's only so many resources to go around when it comes to hacking
> &
Greetings,
* Dave Page (dp...@pgadmin.org) wrote:
> Attached is a patch against 12.4 for the build system in case anyone wants
> to play (I'll do it properly against the head branch later). I'm guessing
> this will work for < 12, as with 12 I'm now getting the following which
> looks like it's rel
Greetings,
* Dave Page (dp...@pgadmin.org) wrote:
> On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost wrote:
> > * Dave Page (dp...@pgadmin.org) wrote:
> > > Attached is a patch against 12.4 for the build system in case anyone
> > wants
> > > to play (I'll do it
Greetings,
* Dave Page (dp...@pgadmin.org) wrote:
> On Wed, Sep 2, 2020 at 9:05 AM Dave Page wrote:
> >> Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> >> used under Windows.
>
> Here's a patch to make it build successfully (against head). I believe the
> changes to Solu
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Mon, 01 Jun 2020 18:00:01 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Rebased on the current HEAD. 36ac359d36 conflicts with this. Tranche
>
> Hmm. This conflicts with 0fd2a79a63. Reabsed on it.
Thanks for working on this
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > The commit 8e19a82640 changed SIGQUIT handler of almost all processes
> > not to run atexit callbacks for safety. Archiver process should behave
> > the same wa
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-08-28 11:46:49 -0400, Tom Lane wrote:
> > It strikes me that when we are vacuuming a temporary table (which
> > necessarily will be one of our own session), we don't really need
> > to care what the global xmin horizon is. If we're
Greetings,
* Dmitry Shulga (d.shu...@postgrespro.ru) wrote:
> Overall archive file processing is done one by one, and this might
> create a performance bottleneck if archived WAL files are delivered slowly,
> because the database server has to wait for arrival of the next
> WAL segment before appl
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This is to pull together a couple of recent threads that are seemingly
> unrelated to $SUBJECT.
>
> Over in the long thread at [1] we've agreed to try to make the backend
> code actually do what assorted comments claim it does, namely allow
> SI
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > Shouldn't this:
> >
> > a) be back-patched, as the other change was
> > b) also include a change to have the stats collector (which I realize is
> >removed later on in this patch set, but we're talking about fixing
> >exi
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote:
>
> > In building off of prior art regarding the 'pg_read_all_data' and
> > 'pg_write_all_data' roles, I would like to propose an extension to roles
> > that would allow for
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Monday, October 11, 2021, Stephen Frost wrote:
> > I don't think "just don't grant access to those other databases"
> > is actually a proper answer- there is certainly a use-case for "
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote:
> > Part of the meeting was specifically about "why are we doing this?" and
> > there were a few different answers- first and foremost was "becaus
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Oct 8, 2021 at 02:34:20PM -0400, Stephen Frost wrote:
> > What I think is missing from this discussion is the fact that, with XTS
> > (and XEX, on which XTS is built), the IV *is* run through a forward
> > cip
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> >
> > > Yes, that's the direction that I was thinking also and specifically
> > with
> > > XTS as the encryption al
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 12, 2021 at 08:25:52AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > > > On Mon, 11 Oct 2021
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 11, 2021 at 1:30 PM Stephen Frost wrote:
> > Regarding unlogged LSNs at least, I would think that we'd want to
> > actually use GetFakeLSNForUnloggedRel() instead of just having it zero'd
> >
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 12, 2021 at 10:31 AM Tom Lane wrote:
> > If the behavior v14 had implemented were "throw an error if the
> > first word doesn't match the current database name", perhaps nobody
> > would have questioned it. But that's not what
Greetings,
On Tue, Oct 12, 2021 at 17:49 Ants Aasma wrote:
>
> On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
>
>> On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
>> > On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
>> >
>> > Well, how do you detect an all-zero page vs a
Greetings,
On Tue, Oct 12, 2021 at 20:26 Bossart, Nathan wrote:
> On 10/9/21, 2:12 AM, "Bharath Rupireddy" <
> bharath.rupireddyforpostg...@gmail.com> wrote:
> > Here's the v1, please review it further.
>
> Thanks for the patch.
>
> - /* Only allow superusers to log memory contexts. */
> -
Greetings,
On Wed, Oct 13, 2021 at 03:54 Michael Paquier wrote:
> On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> > IMO, we can just retain the "if (!superuser())" check in the
> > pg_log_backend_memory_contexts as is. This would be more meaningful as
> > the error "must be
Greeting,
On Wed, Oct 13, 2021 at 04:14 Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Oct 13, 2021 at 1:24 PM Michael Paquier
> wrote:
> >
> > On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote:
> > > IMO, we can just retain the "if (!superuser())" c
Greetings,
* Ants Aasma (a...@cybertec.at) wrote:
> On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> > >
> > > On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wro
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 13, 2021 at 12:54 PM Justin Pryzby wrote:
> > It seems unfortunate if names from log messages qualified with datname were
> > now
> > rejected. Like this one:
> >
> > | automatic analyze of table "ts.child.cdrs_2021_10_12"...
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Thu, 14 Oct 2021 at 09:11, Robert Haas wrote:
> > According to https://www.postgresql.org/docs/current/sql-createview.html
> > it always works like that: "Access to tables referenced in the view is
> > determined by permissions of t
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2021-10-13 at 10:03 -0400, Robert Haas wrote:
> > Yeah. I think we should really only use predefined roles where it's
> > not practical to have people use GRANT/REVOKE.
>
> That sounds like a good rule.
>
> A minor complaint though: to
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Fri, 2021-10-15 at 09:08 -0400, Robert Haas wrote:
> > I think we'd at least need to check that the view owner has execute
> > permission on the function. I'm not sure whether there are any other
> > gotchas.
>
> Right, like we do for tables
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 w
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"
> >>the
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 we s
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,
* 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,
* 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 d
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
people to join 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
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 l
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,
* 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
> >
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 da
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,
* 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
>
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: (1
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,
* 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 role
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 MA
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,
* 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 a
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 t
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 nice
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 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
>
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,
* 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, becaus
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 own
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;
> > GRANT
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
> >
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 only a
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 thin
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,
* 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,
* 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 CHECKP
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 the
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. Maybe
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
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,
* 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 all
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, partic
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 thi
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" support
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 p
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 w
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 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 REPLA
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 *so
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,
* 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
> > b
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,
* 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 "repl
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
> > t
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,
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, th
301 - 400 of 1955 matches
Mail list logo
