Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 1 July 2014 18:32, Stephen Frost wrote:
> > Having functions to control the auditing would work, but it's not
> > exactly the ideal approach, imv, and
>
> What aspect is less than ideal?
I certainly don
e there is sufficient agreement that it'd
be worthwhile to really start implementing this? I'd suggest that we
either forgo or at least table the notion of per-column policy
definitions- RLS controls whole rows and so I don't feel that per-column
policies really make sense.
Thanks,
Stephen
signature.asc
Description: Digital signature
ne leaving this open for now at least
('waiting on author' perhaps) and then bumping it to August only if
necessary. I'm still very interested in getting this committed early in
this cycle to allow for a good bit of testing, of course.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost wrote:
> >> But you could do it other ways. For example:
> >>
> >> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
> >> ALTER TABLE table_name GRANT ROW ACCESS
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost wrote:
> >> > What if policies exist and they decide to
> >> > 'turn off' RLS for the table- suddenly everyone can see all the rows?
> >>
> >
e() against the aclitem array. Any which apply are
added and OR'd together.
Thoughts?
Thanks,
Stephen
signature.asc
Description: Digital signature
able (I'd guess 'yes' just
based on the reduction in NTUP_PER_BUCKET, but did you make any changes
due to the rehashing cost?)?
Thanks,
Stephen
signature.asc
Description: Digital signature
expose "credential" or "secret" rows by interaction of orthogonal policy
> configured by application-2 (that may configure the policy according to the
> source ip-address). It seems to me application-2 partially invalidated the
> RLS-policy configured by application-1.
You are suggesting instead that if application 2 sets up policies on the
table and then application 1 adds another policy that it should reduce what
application 2's users can see? That doesn't make any sense to me. I'd
actually expect these applications to at least use different roles anyway,
which means they could each have a single role specific policy which only
returns what that application is allowed to see.
> I think, an important characteristic is things to be invisible is invisible
> even though multiple rules are configured.
This is addressed through the ability to associate roles to policies.
Thanks,
Stephen
model just some reasonable bloom filter size that we're pretty
> sure will usually help more than it hurts.
This would help out a lot of things, really.. Perhaps what Tomas is
developing regarding test cases would help here also.
Thanks,
Stephen
signature.asc
Description: Digital signature
m all), I don't think
we'd actually solve the use-cases you're describing with either answer.
Without getting to the full level of having the flexibility to choose
which policies should be AND'd and which should be OR'd, do you see an
issue with adding initial support where each policy has to stand on its
own and then working to address the more complex cases later?
Thanks,
Stephen
signature.asc
Description: Digital signature
round here somewhere too, if necessary.
Thanks,
Stephen
signature.asc
Description: Digital signature
ndle these. At this point, I'm open to
simply throwing an ERROR in cases which are not well defined or which do
not work as expected. Ideally we can do better than that, but throwing
an ERROR for cases which don't exist today and which are not yet
supported is reasonable, imv.
> It's already a decent sized amount of work on top of the existing row
> security patch.
Indeed.
> If we start adding policy groups, etc, this will never get done.
Agreed!
Thanks!
Stephen
signature.asc
Description: Digital signature
fficient for what you're looking for? That seems a
simple enough addition which would still allow more complex groups to be
developed later on...
Thanks!
Stephen
signature.asc
Description: Digital signature
on't declare the policy explicitly before setting the
quals, those are done at the same time.
Thanks,
Stephen
signature.asc
Description: Digital signature
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> 2014-07-09 15:07 GMT+09:00 Stephen Frost :
> > * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> >> What I'd like to implement is adjustment of query like:
> >> SELECT * FROM t1 WHERE (x like &#x
On Thursday, July 10, 2014, Robert Haas wrote:
> On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost > wrote:
> > Yes, this would be possible (and is nearly identical to the original
> > patch, except that this includes per-role considerations), however, my
> > thinking is
Robert,
On Friday, July 11, 2014, Robert Haas wrote:
> On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost > wrote:
> > My feeling at the moment is that having them be per-table makes sense and
> > we'd still have flexibility to change later if we had some compelling
>
Tomas,
* Tomas Vondra (t...@fuzzy.cz) wrote:
> On 6.7.2014 17:57, Stephen Frost wrote:
> > * Tomas Vondra (t...@fuzzy.cz) wrote:
> >> I can't find the thread / test cases in the archives. I've found this
> >> thread in hackers:
> >>
> &
r" with quals "42".
>
> Pick a different syntax.
Yeah, now that we're trying to bake this into ALTER TABLE we need to be
a bit more cautious. I'd think:
ALTER TABLE tab POLICY ADD ...
Would work though? (note: haven't looked/tested myself)
Thanks!
Stephen
signature.asc
Description: Digital signature
would be to try and make this part of the major version
release process somehow, perhaps explicitly include it as a 'patch' or
task in the last CF before we feature freeze each year.
Thanks,
Stephen
signature.asc
Description: Digital signature
ould we also want the following, so that
> policies could be modified?
>
> ALTER TABLE POLICY ALTER (policy_quals)
Sounds like a good idea to me.
Thanks!
Stephen
signature.asc
Description: Digital signature
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > > > Of course, we handle this in 'GRANT' with 'GRANT ON ALL TABLES', so why
> > > > not 'ALTER TABLE ON ALL TABLES IN TABLESPACE '? that does get
>
a lot of code :-(
Agreed. If we want this, we should handle it on the pg_dump side, not
try and work it out on the pg_restore side.
Thanks,
Stephen
signature.asc
Description: Digital signature
ly runs.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Bruce Momjian (br...@momjian.us) wrote:
> Actually, thinking more, Stephen Frost mentioned that the auditing
> system has to modify database _state_, and dumping/restoring the state
> of an extension might be tricky.
This is really true of any extension which wants to attach infor
every object
type we have, would really make it painful to write extensions which use
that facility.
Thanks,
Stephen
signature.asc
Description: Digital signature
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > This is really true of any extension which wants to attach information
> > or track things associated with roles or other database objects. What
> > I'd like to avoid is having
rop that concern.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> Actually, thinking more, Stephen Frost mentioned that the auditing
> >> system has to modify database _state_, and dumping/restoring the state
> >
Bill,
* Bill Epstein (epste...@us.ibm.com) wrote:
[...]
This should really go to the -general mailing list. The -hackers
mailing list is for discussion regarding developing the PostgreSQL
server itself.
Thanks!
Stephen
signature.asc
Description: Digital
the Debian guidelines and
didn't like what you got- that's not going to change.
Thanks,
Stephen
signature.asc
Description: Digital signature
#x27;ll figure out a way to use a
better compression algorithm than pglz.
Thanks,
Stephen
signature.asc
Description: Digital signature
r 9.5. Or, if existing products
implement such metrics collection already, perhaps some numbers could
be shared with the community to help address this (and other)
questions.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I looked into the issue reported in bug #11109. The problem appears to be
> >> that jsonb's on-disk format is designed in such a way that the leading
&
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 08/07/2014 10:12 PM, Stephen Frost wrote:
> >If you want the specific version, update your deb line. Don't complain
> >because you used the Debian repo that follows the Debian guidelines and
> >didn't like wh
still within the bounds of reason.
>
> FYI, pg_upgrade could be taught to refuse to upgrade from earlier 9.4
> betas and report the problem JSONB columns.
That is *not* a good solution..
Thanks,
Stephen
signature.asc
Description: Digital signature
if we can find a good solution
to keep both compressability and binary-search (and provided it doesn't
delay us many months..).
Thanks,
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > What about considering how large the object is when we are analyzing if
> > it compresses well overall?
>
> Hmm, yeah, that's a possibility: we could redefine the limit at which
> we bail out in term
follow the threads completely to confirm that there was a real issue.
If there is a real issue here, I'd most likely vote to fix it and
backpatch it as a bug, though it's not clear if that would be considered
'good enough' for this case.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I agree that we need to avoid changing jsonb's on-disk representation.
>
> ... post-release, I assume you mean.
Yes.
> > Have I missed where a good suggestion has been made about how to do that
>
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Aug 8, 2014 at 08:25:04PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > FYI, pg_upgrade could be taught to refuse to upgrade from earlier 9.4
> > > betas and repor
PostgreSQL log file"
or something might help. It amazes me how often just telling people to
go *look at the server log file* helps...
Thanks,
Stephen
signature.asc
Description: Digital signature
trained. At least one of those
> policies has to be wrong. Like Andres and Robert, I pick the second one.
Ditto for me. The postmaster going away really is a bad sign and the
confusion due to leftover processes is terrible for our users.
Thanks,
Stephen
signature.
g a 9.3 version of libpq.
I don't believe the 9.3 version of libpq is the issue here at all, see
above..
Thanks,
Stephen
signature.asc
Description: Digital signature
on't particularly like this recommendation
for how to enable logging of replication commands. For one thing, it
means having to remember to set the per-role GUC for every replication
user which is created and that's the kind of trivially-missed step that
can get people into trouble.
Thanks,
Stephen
signature.asc
Description: Digital signature
ly being able to expand this in the future to do
more. What I'd hate to see is having all of this and only ever using it
to say "skip ahead another 1k for JSONB".
Thanks,
Stephen
signature.asc
Description: Digital signature
t's the focus of this discussion and what needs to be addressed
before 9.4 goes out.
Thanks,
Stephen
signature.asc
Description: Digital signature
n't see those as the same at all. I'd like to see improved
flexibility in this area, certainly, but don't want two independent
considerations like these tied to one GUC..
Thanks,
Stephen
signature.asc
Description: Digital signature
that this is a real
concern, I'd suggest you review the rsync binary diff protocol which is
used extensively around the world and show reports of it failing in the
field.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost wrote:
> > Not entirely sure what you're referring to as 'internally generated'
> > here..
>
> Here 'internally generated' means that user doesn't
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost wrote:
> > Regarding this, I'm generally in the camp that says to just include it
> > in 'all' and be done with it- for now.
>
> Okay, but tomorrow if someo
tly, as I mentioned to Alvaro on IRC when I
saw his note.
Thanks,
Stephen
signature.asc
Description: Digital signature
ove
it from the TABLESPACE docs. That's not done yet but I should have time
in the next few days to get that done also and will then commit it all
to master and back-patch to 9.4, barring objections.
Thanks,
Stephen
diff --git a/src/backend/commands/tablecmds.c b/s
Alvaro, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> it from the TABLESPACE docs. That's not done yet but I should have time
> in the next few days to get that done also and will then commit it
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/17/14 5:19 PM, Stephen Frost wrote:
> > Alvaro, all,
> >
> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> >> it from the
I recall that at one point the ODBC driver simply used libpq to
handle the authentication and set everything up, and then switched to
talking directly without libpq. In any case, it'd probably be good to
make sure the attributes you're suggesting are sufficient to meet the
needs of the ODBC driver too.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
> > At first blush, I'd say a whole bunch.. Off the top of my head I can
> > think of:
[...]
> I'm not really sure we need all that. We're not building a gener
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost wrote:
> > Aren't these questions addressed by sslmode?
>
> Not entirely. You can have sslmode=require and have a matching
> certificate. You don't *have* to have
the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.
Thanks,
Stephen
signature.asc
Description: Digital signature
some
> mapping to agree to map to the common names.
Per Apache's documentation, mod_ssl and mod_gnutls support the same set
of environment variables (with the same names even), so I don't buy this
argument either.
Thanks,
Stephen
signature.asc
Description: Digital signature
if there really is, but I'm a lot happier
starting with a larger set and then considering if we can live without
certain things than trying to build up one-by-one over major releases.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Yeah, that's what I remembered. There was an attempt to make that
> > change at one point, but it was reverted due to the lack of batching
> > ability in libpq (without resorti
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> Um, libpq has recently gained the ability to return result fragments,
> >> right? Those didn't exist when libpq-ification of odbc was attemp
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 08/19/2014 06:44 PM, Stephen Frost wrote:
> >>>Hmm. That seems a bit too much. Perhaps provide just the certificate
> >>>itself in DER/PEM format, and have the client parse it (using
> >>>OpenSSL or s
ble to spend more time on
this in the future but it's not a priority currently.
Thanks,
Stephen
signature.asc
Description: Digital signature
have any symbol versioning or anything to address that risk in place..
Thanks,
Stephen
signature.asc
Description: Digital signature
LSNs and also about the odd stepping that you get
as a result of this change when it comes to WAL file names.
Thanks!
Stephen
signature.asc
Description: Digital signature
unlikely that they would do so to reduce it back down to 16MB, so I'm
really not seeing the naming scheme change as a serious
backwards-incompatibility change.
Thanks!
Stephen
signature.asc
Description: Digital signature
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Mar 21, 2017 at 8:10 PM, Stephen Frost wrote:
> >> We've already
> >> created quite a few incompatibilities in this release, and I'm not
> >> entirely eager to just keep cranking them out a
g_monitor is intended for and that the
privileges it has will change over time. If users are not comfortable
with that, then they can use provided script to create their own
'monitor' role- that is specifically why I want to have nothing
hard-coded to pg_monitor though, because otherwise you couldn't have
such a script able to GRANT out a subset of what pg_monitor allows.
Thanks!
Stephen
signature.asc
Description: Digital signature
hich a
DBA/superuser could do themselves with their own role, if they wished to
do so, instead of using pg_monitor.
Thanks!
Stephen
signature.asc
Description: Digital signature
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/22/17 08:46, Stephen Frost wrote:
> > It's not my intent to 'torpedo' this patch but I'm pretty disappointed
> > that we're introducing yet another initdb-time option with, as far a
dated.
>
> Agreed. Added in the attached patch and rebased on 8027556.
I've started looking at this. Seems pretty straight-forward and will
try to get it committed later today.
Thanks!
Stephen
signature.asc
Description: Digital signature
ring the
regression tests unnecessairly.
Thanks!
Stephen
signature.asc
Description: Digital signature
Andrew,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 03/22/2017 11:39 AM, Stephen Frost wrote:
> > * Andrew Dunstan (and...@dunslane.net) wrote:
> >> Sync pg_dump and pg_dumpall output
> > This probably should have adjusted all callers of pg_dump in the
restart for PG10 because that's something which can clearly be
added later without any concerns about backwards-compatibility, but the
same is not true regarding the naming scheme.
Thanks!
Stephen
signature.asc
Description: Digital signature
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 22, 2017 at 12:22 PM, Stephen Frost wrote:
> > While I understand that you'd like to separate the concerns between
> > changing the renaming scheme and changing the default and enabling this
> > optio
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 22, 2017 at 12:51 PM, Stephen Frost wrote:
> > This would clearly be an adjustment to the submitted patch, which
> > happens regularly during the review and commit process and is part of
> > the commitfes
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 22, 2017 at 1:22 PM, Stephen Frost wrote:
> > To put this in another light, had this issue been brought up post
> > feature-freeze, your definition would mean that we would only have the
> > option to ei
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 22, 2017 at 1:49 PM, Stephen Frost wrote:
> > Then perhaps we do need to be thinking of moving this to PG11 instead of
> > exposing an option that users will start to use which will result in WAL
> > naming
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Thu, Mar 23, 2017 at 12:37 AM, Stephen Frost wrote:
> > * David Steele (da...@pgmasters.net) wrote:
> >> On 3/21/17 2:34 PM, Fujii Masao wrote:
> >> >The patch basically looks good to me, but one comment is;
&
* David Steele (da...@pgmasters.net) wrote:
> On 3/22/17 3:09 PM, Stephen Frost wrote:
> >* Robert Haas (robertmh...@gmail.com) wrote:
> >>On Wed, Mar 22, 2017 at 1:49 PM, Stephen Frost wrote:
> >>>Then perhaps we do need to be thinking of moving this to PG11 inst
e expect to
last us for at least a couple of releases for different sizes of WAL
files, then I don't think we should rush to encourage users to use
different sizes of WAL files.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/22/17 15:14, Stephen Frost wrote:
> >> -SELECT * FROM pg_stop_backup(false);
> >> +SELECT * FROM pg_stop_backup(false [, true ]);
> >>
> >> I think that it's better to get rid of &quo
y the size divided by 16MB, always.
I do also like Peter's suggestion also of using separator between the
components of the WAL filename, but that would change the naming for
everyone, which is a concern I can understand us wishing to avoid.
From a user-experience point of view, keeping the mapping from the WAL
filename to the starting LSN is quite nice, even if this change might
complicate the backend code a bit.
Thanks!
Stephen
signature.asc
Description: Digital signature
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Wed, Mar 22, 2017 at 3:46 PM, Dave Page wrote:
> > On Wed, Mar 22, 2017 at 1:15 PM, Stephen Frost wrote:
> >> I did specifically ask for explicit roles to be made to enable such
> >> capability and that the pg_monitor
ded to be run in parallel isn't
> likely to work out well, but it's always possible somebody has a cases
> where it happens to be winning, and this could break it. So maybe I
> should do this only in master? Thoughts?
For my 2c, I'd back-patch it.
Thanks!
Stephen
signature.asc
Description: Digital signature
d
to understand the file naming, but those are ones I know of off-hand.
Thanks!
Stephen
signature.asc
Description: Digital signature
ion and we need to document for them how to do
so correctly.
Thanks!
Stephen
signature.asc
Description: Digital signature
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/22/17 09:17, Stephen Frost wrote:
> >> If we do it via GRANTs instead, then users can easily extend it.
> > The intent here is that users will *also* be able to do it via GRANTs if
> > they wish to
away with the 'segment'
> thing altogether. You have timelines, and you have files. That's it.
I'm not sure I follow this proposal. We have to know which WAL file has
which LSN in it, how do you do that with just 'timelines and files'?
Thanks!
Stephen
signature.asc
Description: Digital signature
gt; that make sense?
>
> IMHO, it's good to have COMMENT and SECURITY LABEL support for pretty
> much everything.
+1
Thanks!
Stephen
signature.asc
Description: Digital signature
n is already
> grantable, so granting it by default to a built-in role is just
> removing flexibility which would otherwise be available to the user.
To remove flexibility would require that we remove the ability to
independently GRANT that right. We are not doing that. Nor are we
taking anything away from the user by added a new default role- we
already claimed the pg_ namespace for roles in 9.6.
Thanks!
Stephen
signature.asc
Description: Digital signature
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 24, 2017 at 8:30 AM, Stephen Frost wrote:
> >> But why not do it with GRANTs in the first place then?
> >
> > This is akin to asking why do we need GRANT ALL and ALTER DEFAULT PRIVs.
I wasn't very
h the LSN-based
approach, we aren't jumping randomly but exactly in-line with what the
starting LSN of the file is, and always by the same amount (in hex).
Thanks!
Stephen
signature.asc
Description: Digital signature
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/24/17 08:18, Stephen Frost wrote:
> > Beyond that, this also bakes in an assumption that we would then require
> > access to a database
>
> That is a good point, but then any change to the naming wha
st for membership
> >> in that role. I'm struggling to think of all the security implications of
> >> that.
> >
> > This would be the first.
>
> Isn't pg_signal_backend an existing precedent?
Yes, it is.
Thanks!
Stephen
signature.asc
Description: Digital signature
ay to grant access to run this function on a table
besides giving SELECT rights on the entire table to the user. This
would fall under the mandate of the role described in your next bullet,
in my view.
> - Stephen suggested a separate role for functions that can lock
> tables. Is this still de
m just thinking about unintended consequences.
Certainly, good to think of, but I don't believe there's a concern here.
Thanks!
Stephen
signature.asc
Description: Digital signature
left the barn.
Right, which means that, in addition to the points made above, this
isn't a use-case which is actually even all that interesting to
consider.
Thanks!
Stephen
signature.asc
Description: Digital signature
401 - 500 of 4541 matches
Mail list logo
