* Joe Conway (m...@joeconway.com) wrote:
> On 03/01/2016 08:00 AM, Tom Lane wrote:
> > Joe Conway writes:
> >> Would it be a terrible idea to add some attribute to ACLs which can be
> >> used to indicate they should not be dumped (and supporting syntax)?
> >
> > Yes, we'd need some way to mark no
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> [ trimming -novice from the cc list ]
>
> Jeff Janes writes:
> > On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote:
> >> (Problem is reproducible in 9.5 and HEAD, but not 9.4.)
>
> > Bisects down to:
>
> > 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the fi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Tobias Florek writes:
> > When creating an index to use for an ORDER BY clause, a simple query
> > starts to return more results than expected. See the following detailed
> > log.
>
> Ugh. That is *badly* broken. I thought maybe it had something to do w
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> To make this work, you'd need a way to distinguish privileges installed
> >> by initdb from those changed later.
>
> > To replicate whatever t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Per discussion about the best approach to reduce the amount of
> > superuser-only capabilities, this patch modifies pg_dump to dump out
> > all ACLs which exist on objects in the pg_catalog schema.
>
&
o patches, the
first to formally reserve 'pg_', the second to add the new default role.
Will add to the March commitfest for review.
Thanks!
Stephen
From 4a14522ec7ec7d25c3ce9d07f6525b76f6bab598 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Mon, 29 Feb 2016 21:27:46 -0500
Subject
ephen
From b2b01b498f3d9fede2e876785effd48f00feee34 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Mon, 29 Feb 2016 21:11:46 -0500
Subject: [PATCH] Make pg_dump dump ACLs for pg_catalog objects
Historically, we've avoided dumping anything about the objects in
the pg_catalog schema. Unfortunately, this has meant t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Wed, Feb 17, 2016 at 9:48 PM, Tom Lane wrote:
> >> I just had a rather disturbing thought to the effect that this entire
> >> design --- ie, parallel workers taking out locks for themselves --- is
> >> fundamentally flawed. As f
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Christoph Berg writes:
> > The attached patch has successfully been included in the 9.6 Debian
> > package, passed the regression tests there, and I've also done some
> > chmod/chown tests on the filesystem to verify it indeed catches the
> > cases laid out
Joe, all,
* Joe Conway (m...@joeconway.com) wrote:
> On 02/21/2016 08:38 AM, Tom Lane wrote:
> > Coverity griped about use of unchecked strcpy() into a local variable.
> > There's unlikely to be any actual bug there, since no caller would be
> > passing a path longer than MAXPGPATH, but nonetheles
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Now, I have heard it argued that the OpenSSH/L authors are a bunch of
> idiots who know nothing about security. But it's not like insisting
> on restrictive permissions on key files is something we invented out
> of the blue. It's pretty standard pra
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Further, the notion that *this* is the footgun is completely off the
> > reservation- if the files have been changed to allow untrusted users to
> > have access to them, there isn't diddly
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > ... We don't prevent the user from making the
> > configuration file world-writable either,
>
> Maybe we should. It wasn't an issue originally, because the config files
> were necessarily inside $PGDATA which we restrict permissi
Greetings,
While getting back into the thread Re: Optimization for updating foreign
tables in Postgres FDW, I noticed some issues with the docs and
GetExistingLocalJoinPath():
GetExistingLocalJoinPath() exists in src/backend/foreign/foreign.c, but
the docs include discussion of it under 54.2 - Fo
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Feb 15, 2016 at 10:23 AM, Stephen Frost wrote:
> > I would start by pointing out that pg_user currently uses pg_shadow..
> > Why do we need pg_shadow or pg_user or related views at all..?
>
> pg_user/pg_shadow
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Why do we need pg_shadow or pg_user or related views at all..?
>
> A lot of code looks at those just to get usernames. I am not in favor of
> breaking such stuff without need.
Alright.
> How about we just
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> It seems to me that applications are going to need a refresh anyway...
Indeed.
> Among the other possibilities I can foresee:
> - Add a column "protocol" to pg_shadow and produce one row per
> protocol, so one user will be listed fo
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Feb 15, 2016 at 9:17 AM, Stephen Frost wrote:
> > That said, per various discussions, we'd really want a more-or-less
> > fully formed patch to land prior to the last CF, for this to have any
> > c
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Feb 13, 2016 at 3:05 AM, David Steele wrote:
> > On 11/16/15 8:53 AM, Michael Paquier wrote:
> >> On Sat, Sep 5, 2015 at 9:31 AM, Bruce Momjian wrote:
> >>> On Fri, Sep 4, 2015 at 04:51:3
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 14 February 2016 at 08:05, Robert Haas wrote:
> > First, the overall concept here is that processes can either be a
> > member of a lock group or a member of no lock group. The concept of a
> > lock group is formally separate from the concept of
p 17 00:00:00 2001
From: Stephen Frost
Date: Wed, 10 Feb 2016 13:28:11 -0500
Subject: [PATCH] Add note regarding permissions in pg_catalog
Add a note to the system catalog section pointing out that while
modifying the permissions on catalog tables is possible, it's
unlikely to have the
* David Steele (da...@pgmasters.net) wrote:
> On 2/10/16 9:44 AM, Stephen Frost wrote:
> > Hrmmm. If that's the case then perhaps you're right. I liked the
> > general idea of not having to maintain a TCP connection during the
> > entire backup (TCP connectio
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund wrote:
> > On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > > Per discussionat the developer meeting in Brussels, here's a patch that
> > > makes some updates to the backup APIs, to support non-
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > * If the client disconnects with a non-exclusive backup running, the backup
> > is automatically aborted. This is the same thing that pg_basebackup does.
> > To use these non-exclusive backups the
* Joe Conway (m...@joeconway.com) wrote:
> On 02/09/2016 01:22 PM, Tom Lane wrote:
> > Maybe we need to restrict that somehow, or maybe some better solution
> > exists that we've not thought of yet. But in its current state, RLS
> > is at least as much a security hazard as it is a security aid.
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > Personally I don't buy that the current situation is a good thing. I
> > know that the "ship has sailed" and regret not having participated in
> > the earlier discussions, but I agree with JD here -- the unprivileged
> > user sh
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 February 2016 at 19:47, Robert Haas wrote:
> > I think you're dismissing Tom's concerns far too lightly. The
> > row_security=off mode, which is the default, becomes unusable for
> > non-superusers under this proposal. That's bad. And if y
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake (j...@commandprompt.com) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> > To the extent that untrusted code execution is an issue (and my
> > experience with environments which would deploy RLS tells me that it
> > isn't a practical co
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> pg_dump -U $non-super_user
>
> Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Thanks!
Stephen
signature.asc
Description: Digital s
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> > On 02/09/2016 11:47 AM, Robert Haas wrote:
> >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
> >>>> Whereupon you'd have no cer
Thomas,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Tue, Feb 9, 2016 at 5:30 AM, Joe Conway wrote:
> > On 02/08/2016 06:24 AM, Andres Freund wrote:
> >> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
> >>> Now that there is a setting to give a cluster a "name", it would be nice
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm of the opinion that this is a stop-ship bug for 9.5.1. Barring
> somebody producing a fix over the weekend, I will deal with it by
> reverting the aforementioned commit.
Agreed.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Joe Conway (m...@joeconway.com) wrote:
> On 02/05/2016 10:16 AM, Stephen Frost wrote:
> > An in-core auditing solution would provide us with proper grammar
> > support, ability to directly mark objects for auditing in the catalog,
> > allow us to much more easily maintai
All,
* Robert Haas (robertmh...@gmail.com) wrote:
> OK, I'll bite: I'm worried that this patch will be a maintenance
> burden. It's easy to imagine that changes to core will result in the
> necessity or at least desirability of changes to pgaudit, but I'm
> definitely not prepared to insist that
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> wrote:
> >> > Personally, I don't
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost wrote:
> >> So, this seems like a case where a built-in role would be
> >> well-justified. I don't really believe in built-in roles as a way of
> >> bundling relate
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote:
> > * Joshua D. Drake (j...@commandprompt.com) wrote:
> > > On 01/28/2016 06:57 AM, Robert Haas wrote:
> > >
> > > >>I'm on board with Bruce&
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other issue tha
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 01/28/2016 06:57 AM, Robert Haas wrote:
>
> >>I'm on board with Bruce's template as being a checklist of points to be
> >>sure to cover when composing a commit message. I'm not sure we need
> >>fixed-format rules.
> >
> >Well, I think what pe
José,
* José Arthur Benetasso Villanova (jose.art...@gmail.com) wrote:
> I wrote 2 possible patches, both issuing a detail message only if
> log_connections is enabled.
>
> The first one using the Stephen Frost suggestion, inside the Port struct (I
> guess that this is the one,
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will
> > be moving the buildfarm server from its current home at CommandPrompt,
>
> Um, this message is postmarked 18 Jan 17:20, an hour later than
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote:
> > Meh, that seems pretty far into pseudo security arguments.
>
> Yeah, I really don't see anything in the pg_controldata output that
> looks sensitive. The WAL locations are the closest of anyt
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote:
> > > > Group ownership and permissions aren't a backup-method-specific
> > > > requirement either, in my view. I'm happy to chat with Marco (who has
&g
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote:
> > > While the group owner of the directory is a distributions question, the
> > > permissions are usually a backup-method-specific requirement. I can see
> > &g
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 06:58:25PM -0500, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other is
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote:
> > Right, we also check in the backend on startup for certain permissions.
> > I don't recall offhand if that's forced to 700 or if we allow 750.
> >
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Jan 6, 2016 at 12:29:14PM -0500, Robert Haas wrote:
> > The point is that with the GRANT EXECUTE ON FUNCTION proposal, authors
> > of monitoring tools enjoy various really noteworthy advantages. They
> > can have monitoring roles which have *exa
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > > pgbackrest:
> > > >
> > > > To run pgbackrest as a non-superuser and not the 'po
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those process
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > What I think we really want here is logging of the general 'system
> > user' for all auth methods instead of only for the 'peer' method.
>
> Well, we don't really know that
José,
* José Arthur Benetasso Villanova (jose.art...@gmail.com) wrote:
> Here in my work, we have about 100 PostgreSQL machines and about 20 users
> with superuser privileges.
Sounds pretty common. What kind of superuser rights are they using?
What is the minimum set of rights that are required
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost writes:
> >>> I don't follow how this would destroy the ability to run pg_dump.
> >>> Ideally, we'd have a result wh
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> However, by "not that much trouble" I only mean getting an implementation
> >> that works and doesn't create more security problems than it fix
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > As Stephen mentioned, yes, I am very interested in at least some aspects
> > of this patch. The ability to apply RLS to system tables could be useful
> > to solve a number of problems we don't have a good story for today,
> > multi-te
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
> wrote:
> > May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> > because 4_database_catalog_tenancy_v5 patch depends on it.
> >
> > Here I attached all the patches for your conv
Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 4:56 PM, Stephen Frost wrote:
> >> First, it's not really going to matter to users very much whether the
> >> command to enable one of these features is a single GRANT command or a
> >> short sequence of G
Jim, all,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> Which doesn't help anyone, because neither of those provide a list
> of "hey, here's stuff you could do to contribute". The closest we
> come to that is the TODO, which isn't well known and has almost no
> items for newbies (and the newbie
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost wrote:
> > I'm not sure it's entirely relevant now- I've outlined the reasoning in
> > my email to Noah as a, hopefully, pretty comprehensive summary. If that
> > d
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 12:55 PM, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those processes.
* Peter Geoghegan (p...@heroku.com) wrote:
> On Mon, Jan 4, 2016 at 12:13 PM, Tom Lane wrote:
> > I've pushed an example based on your original test case. Feel free
> > to suggest improvements, although at this point they'll probably
> > land in 9.5.1.
>
> I think that that's a vast improvement.
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote:
> > The proposed pg_replication role introduces abstraction that could, as you
> > hope, spare a DBA from studying sets of functions to grant together. The
> > pg_rotate_logfile role, however
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> > Updated patch attached. I'll give it another good look and then commit
> >> > it, barring objections.
>
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
>
> > The one argument which you've put forth for adding the complexity of
> > dumping catalog ACLs is that
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The RLS patch added this to struct Query:
>
> List *withCheckOptions;/* a list of WithCheckOption's, which
> * are only added during rewrite and
> * the
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 11:55 PM, Stephen Frost wrote:
> > I could go either way on that, really. I don't find namespace to be
> > confusing when used in that way, but I'll change it since others do.
>
> It
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > As we don't want to end up with the same behavior-change-due-to-GUC that
> > we had with the original row_security implementation, we should change
> > the code as your patch does and update the re
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Sunday, January 3, 2016, Tom Lane wrote:
> >> The fine manual says that when row_security is set to off, "queries fail
> >> which would otherwise apply at least one policy". However, a
Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 6:09 PM, Peter Geoghegan > wrote:
> >> I think we should get rid of it altogether (since I also agree with the
> >> upthread comment that it's in the wrong place) and instead put an
> example
> >> into section 5.
Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane >
> wrote:
> > In any case, the text in create_policy.sgml seems to be a misleading
> > description of the problem, as it's talking about DDL modifications
> > which are *not* what's happening he
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> Peter Geoghegan > writes:
> > On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane > wrote:
> >> If we fix this, I believe we could also remove the weasel wording that
> was
> >> added to create_policy.sgml in commit 43cd468cf01007f3 about how the
> >> sys
Tom, Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane >
> wrote:
> > CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> > added to -- good -- and then releases it when done -- bad. Correct
> > behavior is to hold the lock
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> The fine manual says that when row_security is set to off, "queries fail
> which would otherwise apply at least one policy". However, a look at
> check_enable_rls() says that that is a true statement only when the user
> is not table owner. If
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> added to -- good -- and then releases it when done -- bad. Correct
> behavior is to hold the lock till commit, because otherwise there is
> no guarantee that other backend
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2015/12/23 7:23, Stephen Frost wrote:
> > Updated patch attached. I'll give it another good look and then commit
> > it, barring objections.
>
> Just a minor nitpick about a code comment -
>
>
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> > Updated patch attached. I'll give it another good look and then commit
> > it, barring objections.
>
> This thread and its satellite[1] have worked their way through a few designs.
> At first, it was adding role attributes, alongside existing att
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 22, 2015 at 2:54 PM, Amit Langote
> wrote:
> > On 2015/12/22 14:05, Michael Paquier wrote:
> >> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
> >>> Updated and rebased patch attache
7;m going to
be going through it also more closely since it sounds like we've got
consensus on at least this initial set of default roles and rights. If
all looks good then I'll commit it.
Thanks!
Stephen
From 59bda4266a96976547e0aa44874ad716bf3dbdc9 Mon Sep 17 00:00:00 2001
From:
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 1, 2015 at 9:18 AM, Michael Paquier
> wrote:
> > OK, let's do so then by having this one fall under pg_backup. Let's
> > not be my grunting concerns be an obstacle for this patch, and we
> > could still change it afterwar
* Robert Haas (robertmh...@gmail.com) wrote:
> This appears to address one of the open items at
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items -- if so,
> please update that page.
Done (and re-done with the wiki restore).
No open items remain against 9.5.
Thanks!
Stephen
signatu
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 12/11/15 4:12 PM, Stephen Frost wrote:
> > As with ACLs, the DROP OWNED BY caller must have permission to modify
> > the policy or a WARNING is thrown and no change is made to the policy.
>
> That warning doesn't tell the
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 4, 2015 at 3:22 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> Stephen Frost wrote:
> >> > Still, I'll get a patch worked up for it and then we can discuss the
>
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Still, I'll get a patch worked up for it and then we can discuss the
> > merits of that patch going in to 9.5 now versus just into HEAD.
>
> Cool.
While working on the DROP OWNED BY patch,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I noticed in passing that the role removal documentation should really
> > also discuss shared objects (as the DROP OWNED BY reference page does).
>
> If you're speaking of section 20.4, that text is
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost wrote:
> > >
> > > > The non-documentation question is around DROP OWNED. We need to either
> >
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > The non-documentation question is around DROP OWNED. We need to either
> > have policies dropped by DROP OWNED (well, roles removed, unless it's
> > the last one, in which case the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, it's December nearly, and we don't seem to be making much progress
> towards pushing out 9.5.0. I see the following items on
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>
> * Open Row-Level Security Issues
>
> Seems like what's left
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> >> > * Michael Paquier (michael.paqu...@gmai
On Tuesday, November 24, 2015, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>
> > Even so, in the interest of having more fine-grained permission
> > controls, I've gone ahead and added a pg_switch_xlog default role.
> > Note that this means that pg_switch
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Nov 21, 2015 at 2:29 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > Even so, in the interest of having more fine-grained permission
> > controls, I'
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Sep 28, 2015 at 03:03:51PM -0400, Stephen Frost wrote:
> > If SELECT rights are required then apply the SELECT policies, even if
> > the actual command is an UPDATE or DELETE. This covers the RETURNING
> > cas
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Jul 28, 2015 at 04:04:29PM -0700, Joe Conway wrote:
> > Pushed to HEAD and 9.5
>
> I reviewed this commit, f781a0f "Create a pg_shdepend entry for each role in
> TO clause of policies."
Thanks for the review!
> This commit rendered the
>
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> It seems weird to not have a dedicated role for pg_switch_xlog.
> >
> > I didn't add a
primary function which
is being called into. If there is really a push to go back to having a
'check_permissions()' like function, I'd argue that we should make the
function name more descriptive of what's actually being done and have
them be distinct from each other. As I recal
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> Will there be any work on this patch for this commit fest or not? This
> is being carried around for a couple of months now with not much
> progress. This thread is idle for 4 months now.
This thread and the other one kind of merged.
JD,
On Wednesday, November 4, 2015, Joshua D. Drake
wrote:
> On 11/04/2015 02:15 PM, Stephen Frost wrote:
>
> Yeah but anything holding a lock that long can be terminated via
>>> statement_timeout can it not?
>>>
>>
>> Well, no? statement_timeout is p
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 11/04/2015 01:55 PM, Stephen Frost wrote:
> >* Joe Conway (m...@joeconway.com) wrote:
> >>On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> >>>I agree with Pavel. Having a transaction timeout just does not m
* Joe Conway (m...@joeconway.com) wrote:
> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> > I agree with Pavel. Having a transaction timeout just does not make any
> > sense. I can see absolutely no use for it. An idle-in-transaction
> > timeout, on the other hand, is very useful.
>
> +1 -- ag
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
> >>
> >> rhaas=# create policy
* Robert Haas (robertmh...@gmail.com) wrote:
> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
>
> rhaas=# create policy hideit on foo1 using (a < 3);
> CREATE POLICY
> rhaas=# explain select * from foo1;
>QUERY PLAN
>
901 - 1000 of 4446 matches
Mail list logo
