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
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
* Tom Lane ([email protected]) 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.
>
&
* Tom Lane ([email protected]) wrote:
> Stephen Frost writes:
> > * Tom Lane ([email protected]) 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 ([email protected]) 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 ([email protected]) 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
* Joe Conway ([email protected]) 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
* David G. Johnston ([email protected]) wrote:
> On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote:
> > Rather than have two aclitem[] columns in every catalog, since this
> > information is only used by pg_dump and not during normal operation, we
> > could
* Joe Conway ([email protected]) wrote:
> On 03/02/2016 12:54 PM, Stephen Frost wrote:
> > * Joe Conway ([email protected]) wrote:
> >> On 03/01/2016 08:00 AM, Tom Lane wrote:
> >>> Yes, we'd need some way to mark non-null ACLs as being "built-in
> &g
* Andres Freund ([email protected]) wrote:
> On 2016-03-03 18:31:03 +0100, Magnus Hagander wrote:
> > I think we want it at protocol level rather than pg_basebackup level.
>
> I think we may want both eventually, but I do agree that protocol level
> has a lot higher "priority" than that. Somethin
* Joe Conway ([email protected]) wrote:
> On 03/07/2016 01:43 PM, Josh berkus wrote:
> > http://blogs.microsoft.com/?p=67248
> >
> > Once SQL Server is available on Linux, we're going to see more people
> > using it as an alternative to PostgreSQL. Especially since they're
> > picking up a lot o
* Tom Lane ([email protected]) wrote:
> In connection with a question on -general, I tried this:
>
> $ pg_dump -n '*' regression >regression.dump
> pg_dump: WARNING: typtype of data type "any" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid
> pg_dum
* Tom Lane ([email protected]) wrote:
> Stephen Frost writes:
> > * Tom Lane ([email protected]) wrote:
> >> pg_dump: WARNING: typtype of data type "any" appears to be invalid
>
> > This is fixed in my changes to pg_dump, though I didn't expect
* Tom Lane ([email protected]) wrote:
> Stephen Frost writes:
> > I think the real question is if "-n '*'" should still exclude
> > 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
> > but aren't you going to end up
* Tom Lane ([email protected]) wrote:
> Thomas Munro writes:
> > Is the plan to remove support for floating point timestamps at some
> > stage? If so, what is that waiting on, and would it provide
> > sufficient warning if (say) 9.6 were documented as the last major
> > release to support that b
* Alvaro Herrera ([email protected]) wrote:
> Simon Riggs wrote:
> > On 10 March 2016 at 06:53, Michael Paquier
> > wrote:
> >
> > > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> > > wrote:
> > > > Robert Haas wrote:
> > > >> I'm pretty meh about the whole idea of this function, thoug
> columns, one that is expected to be frozen after initdb and one for
> user-added grants.
This is along the lines of what I've done, but I've used a new catalog
instead, which is quite small and doesn't complicate or change the
regular catalogs.
* Joe Conway ([email protected]
* Julien Rouhaud ([email protected]) wrote:
> On 15/03/2016 03:30, Peter Geoghegan wrote:
> > On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
> >> Attached patch fixes a bug reported privately by Stephen this morning.
> >
> > Bump.
> >
> > I would like to see this in the next poin
* Alvaro Herrera ([email protected]) wrote:
> Stephen Frost wrote:
> > * Julien Rouhaud ([email protected]) wrote:
>
> > XLTW_InsertIndexUnique is used when building a unique index, but this is
> > just a check, and more to the point, it's actually
* Robert Haas ([email protected]) wrote:
> On Mon, Feb 29, 2016 at 10:02 PM, Stephen Frost wrote:
> > Attached is a stripped-down version of the default roles patch which
> > includes only the 'pg_signal_backend' default role. This provides the
> > framework
Robbie,
* Robbie Harwood ([email protected]) wrote:
> Michael Paquier writes:
> > - maj_stat = gss_accept_sec_context(
> > - &min_stat,
> > + maj_stat = gss_accept_sec_context(&min_stat,
> >
> > This is just noise.
>
> You're not wrong, thoug
Robert, all,
* Robert Haas ([email protected]) wrote:
> On Fri, Mar 18, 2016 at 9:31 AM, Michael Paquier
> wrote:
> > That's not an issue for me to rebase this set of patches. The only
> > conflicts that I anticipate are on 0009, but I don't have high hopes
> > to get this portion integrating
Peter,
* Peter Geoghegan ([email protected]) wrote:
> Thinking about this again, I think we should use
> XLTW_InsertIndexUnique after all. The resemblance of the
> check_exclusion_or_unique_constraint() code to the nbtinsert.c code
> seems only superficial on second thought. So, I propose fixing the
* Merlin Moncure ([email protected]) wrote:
> On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote:
> > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote:
> >> Do I understand correctly the only way know availability PREPARE it will
> >> appeal to pg_prepared_statements?
> >> I think this is not
* Andres Freund ([email protected]) wrote:
> On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote:
> > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote:
> > > Hi,
> > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote:
> > >> Do I understand correctly the only way know availability PREPARE it
Merlin,
* Merlin Moncure ([email protected]) wrote:
> No one is arguing that that you should send it any every time (at
> least -- I hope not).
I'm not sure I follow how you can avoid that though?
pgbouncer in transaction pooling mode may let a particular connection
die off and then, when you i
* Merlin Moncure ([email protected]) wrote:
> On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote:
> > which is both SQL-standard semantics and much more efficient than
> > SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we
> > introduced LATERAL in 9.3. How much are we willing to d
* David G. Johnston ([email protected]) wrote:
> On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote:
> > In the meantime I suppose there's a case to be made for preserving
> > bug compatibility as much as possible.
> >
> > So anyway the question is whether to commit the attached or not.
>
>
* Tom Lane ([email protected]) wrote:
> Robert Haas writes:
> > I am not really in favor of half-fixing this. If we can't
> > conveniently wait until a dropped role is completely out of the
> > system, then I don't see a lot of point in trying to do it in the
> > limited cases where we can. If
All,
Changed the thread name (we're no longer talking about release
notes...).
* Tom Lane ([email protected]) wrote:
> Oleg Bartunov writes:
> > Should we start thinking about ICU ?
>
> Isn't it still true that ICU fails to meet our minimum requirements?
> That would include (a) working with t
Paul,
* Paul Ramsey ([email protected]) wrote:
> I spent some time over the weekend trying out the different modes of
> parallel query (seq scan, aggregate, join) in combination with PostGIS
> and have written up the results here:
>
> http://blog.cleverelephant.ca/2016/03/parallel-postgis
* Peter Geoghegan ([email protected]) wrote:
> On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote:
> > If we're going to talk about minimum requirements, I'd like to argue
> > that we require whatever system we're using to have versioning (which
> > glibc
* Michael Paquier ([email protected]) wrote:
> On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote:
> > On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote:
> >> v40 is yet another rebase.
> >
> > Thanks. Committed after removing an unnecessary parameter from the
> > coerceToXXX() functi
* José Luis Tallón ([email protected]) wrote:
> * Prepend a [review] tag to the e-mail subject
> ... so that e-mails sent to -hackers will read " [HACKERS]
> [review] "
Eh, I'm not against it but not sure it's all that necessary either.
> * Auto-CC the patch author on this e-mail
>
* Tom Lane ([email protected]) 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
* Tom Lane ([email protected]) wrote:
> Stephen Frost writes:
> > * Tom Lane ([email protected]) 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 ([email protected]) wrote:
> Stephen Frost writes:
> > * Tom Lane ([email protected]) 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
José,
* José Arthur Benetasso Villanova ([email protected]) 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,
* Tom Lane ([email protected]) 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
* Bruce Momjian ([email protected]) 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
* Bruce Momjian ([email protected]) wrote:
> On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> > * Bruce Momjian ([email protected]) wrote:
> > > > pgbackrest:
> > > >
> > > > To run pgbackrest as a non-superuser and not the 'po
* Bruce Momjian ([email protected]) 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,
* Bruce Momjian ([email protected]) 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 ([email protected]) 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 Momjian ([email protected]) 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 ([email protected]) 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
* Robert Haas ([email protected]) 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
Tom, all,
* Tom Lane ([email protected]) 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
José,
* José Arthur Benetasso Villanova ([email protected]) 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,
* Joshua D. Drake ([email protected]) 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
* Robert Haas ([email protected]) 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
* Bruce Momjian ([email protected]) wrote:
> On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote:
> > * Joshua D. Drake ([email protected]) wrote:
> > > On 01/28/2016 06:57 AM, Robert Haas wrote:
> > >
> > > >>I'm on board with Bruce&
* Robert Haas ([email protected]) 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
Michael,
* Michael Paquier ([email protected]) wrote:
> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> > * Robert Haas ([email protected]) wrote:
> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> wrote:
> >> > Personally, I don't
All,
* Robert Haas ([email protected]) 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
* Joe Conway ([email protected]) 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
* Tom Lane ([email protected]) 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
Thomas,
* Thomas Munro ([email protected]) 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
Robert,
* Robert Haas ([email protected]) 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
JD,
* Joshua D. Drake ([email protected]) 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 Haas ([email protected]) 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 ([email protected]) wrote:
> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake ([email protected]) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed
* Dean Rasheed ([email protected]) 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
Tom,
* Tom Lane ([email protected]) 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
* Joe Conway ([email protected]) 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.
>
* Andres Freund ([email protected]) 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
* Magnus Hagander ([email protected]) 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-
* David Steele ([email protected]) 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
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
* Craig Ringer ([email protected]) 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
Michael,
* Michael Paquier ([email protected]) 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
Michael,
* Michael Paquier ([email protected]) 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 ([email protected]) 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
* Tom Lane ([email protected]) 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 Paquier ([email protected]) 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
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
* Tom Lane ([email protected]) 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
Tom,
* Tom Lane ([email protected]) 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,
* Tom Lane ([email protected]) 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
Joe, all,
* Joe Conway ([email protected]) 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 Lane ([email protected]) 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
* Tom Lane ([email protected]) 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
Venkata,
* Venkata B Nagothi ([email protected]) wrote:
> Agreed. Additional option like "pause" would. As long as there is an option
> to ensure following happens if the recovery target is not reached -
>
> a) PG pauses the recovery at the end of the WAL
> b) Generates a warning in the log fil
* Jim Nasby ([email protected]) wrote:
> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> not specify -c for any of the rsync commands. That's maybe safe for
> WAL, but I don't think it's safe for any of the other uses, right?
> I'd like someone to confirm before I just ch
* Venkata B Nagothi ([email protected]) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost wrote:
> > * Venkata B Nagothi ([email protected]) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensu
* Jim Nasby ([email protected]) wrote:
> On 8/17/16 9:46 PM, Stephen Frost wrote:
> >* Jim Nasby ([email protected]) wrote:
> >>> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> >>> not specify -c for any of the rsync commands. Tha
this isn't about default roles (which was the subject of that thread).
Thanks!
Stephen
From b4f04c81c88c126c470a7afc74ea9e4f860be412 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Tue, 23 Aug 2016 17:13:09 -0400
Subject: [PATCH] Remove superuser checks in pgstattuple
Now that we tra
Michael,
* Michael Paquier ([email protected]) wrote:
> The patch attached includes all those tests and they are failing. We
> are going to need a patch able to pass all that, and even for master
> this is going to need more thoughts, and let's focus on HEAD/9.6
> first.
Are you sure you
* Venkata B Nagothi ([email protected]) wrote:
> *Query 1*
>
> What about the existing parameter called "recovery_target" which accepts
> only one value "immediate", which will be similar to the "promote" option
> with the to-be-introduced new parameter.
> Since this parameter's behaviour will be
Robert,
* Robert Haas ([email protected]) wrote:
> Meanwhile, we'll significantly help people who are currently
> generating painfully large but not totally insane numbers of WAL
> segments. Someone who is currently generating 32,768 WAL segments per
> day - about one every 2.6 seconds - will
Robert,
* Robert Haas ([email protected]) wrote:
> On Thu, Aug 25, 2016 at 9:48 AM, Stephen Frost wrote:
> > * Robert Haas ([email protected]) wrote:
> >> Meanwhile, we'll significantly help people who are currently
> >> generating painfully large but n
* Robert Haas ([email protected]) wrote:
> On Thu, Aug 25, 2016 at 10:34 AM, Stephen Frost wrote:
> >> My point wasn't really that archive_command should actually be simple.
> >> My point was that if it's being run multiple times per second, there
> >>
Michael,
* Michael Paquier ([email protected]) wrote:
> On Thu, Aug 25, 2016 at 10:25 PM, Bruce Momjian wrote:
> > On Wed, Aug 24, 2016 at 10:40:06PM -0300, Claudio Freire wrote:
> >> > time instead of requiring a recompile; we probably don't save any
> >> > significant number of cycles b
* Venkata B Nagothi ([email protected]) wrote:
> On Thu, Aug 25, 2016 at 10:59 PM, Stephen Frost wrote:
> > I'm not a fan of the "recovery_target" option, particularly as it's only
> > got one value even though it can mean two things (either "immediate&qu
* Bruce Momjian ([email protected]) wrote:
> On Fri, Aug 26, 2016 at 11:39:29AM +0900, Michael Paquier wrote:
> > Now, one of the things discussed as well was that we may want to still
> > keep pg_xlog, and soft-link to pg_journal or whatever-the-new-name is
> > to not break the existing tools. Pers
* Venkata B Nagothi ([email protected]) wrote:
> On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost wrote:
> > * Venkata B Nagothi ([email protected]) wrote:
> > > This behaviour will be similar to that of recovery_target="immediate" and
> > > can be aliased.
* Tom Lane ([email protected]) wrote:
> Euler Taveira writes:
> > On 26-08-2016 09:25, Devrim Gündüz wrote:
> >> ...and we also have "pg_logical", that includes a "log" keyword already...
>
> > "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine
> > people confusing "logical" me
s.
Thanks!
Stephen
From f4195e9c109d8323266419e487eed2b4cbaafdef Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Thu, 1 Sep 2016 02:11:30 -0400
Subject: [PATCH] Add support for restrictive RLS policies
We have had support for restrictive RLS policies since 9.5, but they
were only available through extensions which use the app
* Robert Haas ([email protected]) wrote:
> On Thu, Sep 1, 2016 at 12:04 PM, Stephen Frost wrote:
> > As outlined in the commit message, this adds support for restrictive RLS
> > policies. We've had this in the backend since 9.5, but they were only
> > availab
* Peter Eisentraut ([email protected]) wrote:
> On 8/23/16 5:22 PM, Stephen Frost wrote:
> > Now that we track initial privileges on extension objects and changes to
> > those permissions, we can drop the superuser() checks from the various
> > functions
1 - 100 of 4446 matches
Mail list logo
