ch with their own IS NULL / STRICT vs isnull and other functions. We
decided that trying to merge both null representing mechanisms would
probably lead to an incomplete merge, and thus many unexpected problems,
and that therefore a clean separation would be easiest to explain and
work with.
regards,
Ye
ting domain. I cannot begin to imagine the kind of security
restrictions you'd need to audit what happens with data after libpq has
produced the results. My best guess would be to incorporate some kind of
separation of duty mechanism; only allow certain superuser operations
with two people involved.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ase, it is probably logical for access to be combined
via OR.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-04-03 09:40, Oleg Bartunov wrote:
Sure, we don't follow. I mean should we add to documentation
such matrices.
Oleg
On Thu, Apr 3, 2014 at 11:32 AM, Oleg Bartunov wrote:
Hi there,
I'm wondering if we should follow all js equility rules as
nicely visualized in
http://strilanc.com/visua
On 05/03/14 15:44, Craig Ringer wrote:
On 03/05/2014 05:25 PM, Yeb Havinga wrote:
Maybe a naive thought, but shouldn't all plans that include a table with
an RLS clause be invalidated when the session role switches, regardless
of which users from and to?
Only if the plan is actually acc
On 06/03/14 02:56, Craig Ringer wrote:
On 03/06/2014 04:56 AM, Yeb Havinga wrote:
If you state it like that, it sounds like a POLA violation. But the
complete story is: "A user is allowed to UPDATE a set of rows from a
table that is not a subsect of the set of rows he can SELECT from the
On 2014-03-05 04:02, Craig Ringer wrote:
On 03/04/2014 09:41 PM, Yeb Havinga wrote:
On 04/03/14 02:36, Craig Ringer wrote:
I've pushed an update to the branch with the fix for varno handling.
Thanks. It's tagged rls-9.4-upd-sb-views-v8 .
I've almost run out of time to spend
On 04/03/14 02:36, Craig Ringer wrote:
On 02/25/2014 01:28 AM, Dean Rasheed wrote:
On 13 February 2014 04:12, Craig Ringer wrote:
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
Given the simplicity of what the row-security code its self is d
On 04/03/14 02:36, Craig Ringer wrote:
On 02/25/2014 01:28 AM, Dean Rasheed wrote:
On 13 February 2014 04:12, Craig Ringer wrote:
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
Given the simplicity of what the row-security code its self is d
On 2014-02-11 12:09, Craig Ringer wrote:
On 02/11/2014 06:05 PM, Yeb Havinga wrote:
On 2014-02-11 09:36, Craig Ringer wrote:
On 02/06/2014 10:19 PM, Craig Ringer wrote:
On 02/06/2014 12:43 PM, Craig Ringer wrote:
1. Try (again) to do row-security in the rewriter. This was previously
On 2014-02-11 09:36, Craig Ringer wrote:
On 02/06/2014 10:19 PM, Craig Ringer wrote:
On 02/06/2014 12:43 PM, Craig Ringer wrote:
1. Try (again) to do row-security in the rewriter. This was previously
impossible because of the definition of row-security behaviour around
inheritance, but with the
.
3. RLS syntax is readable and easy to use.
4. Documentation needs work.
5. Subqueries in RLS quals can be pulled up, so opens the ability for
fast processing.
Overall from a users perspective the patch gave a solid impression.
regards,
Yeb Havinga
Albana Gaba
Henk-Jan Meijer
Portavita
On 2014-02-06 05:43, Craig Ringer wrote:
Based on Tom's objections, another approach is presented in
rls-9.4-upd-sb-views-v5 on g...@github.com:ringerc/postgres.git . The
Query node is used to record the recursive expansion parent list
instead, and copying is avoided.
Cannot fetch or clone.
g
icy applied would be invariant to the route
through which the rows were accessed:
- directly to the child row: child rls quals and parent quals (by
propagate at ddl) are applied.
- through the parent: child rls quals and parent quals applied.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing
On 2014-01-31 16:05, Stephen Frost wrote:
* Yeb Havinga (y.t.havi...@mgrid.net) wrote:
IMHO, there is another way to implement this, other than the
procedure to override the child-rel-quals with the ones from the
parent. At DDL time, synchronize quals on the parent with rls quals
of the childs
f).
The HCS security label is based on the NIST's FIPS188 standard /
http://www.itl.nist.gov/fipspubs/fip188.htm
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-11-14 22:23, Tom Lane wrote:
So after some experimentation I came up with version 2, attached.
Thanks for looking into this! I currently do not have access to a setup
to try the patch. A colleague of mine will look into this next week.
Thanks again,
Yeb Havinga
--
Sent via pgsql
On 2013-09-13 18:32, Robert Haas wrote:
On Thu, Sep 12, 2013 at 5:29 AM, Yeb Havinga wrote:
Is the following known behaviour, or should I put some time in writing a
self contained test case?
We have a function that takes a value and returns a ROW type. With the
function implemented in
own
behavior of SQL functions vs PL/pgSQL functions, or could it be a bug?
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-06-07 19:09, Fred&Dani&Pandora&Aquiles wrote:
I asked a while ago in this group about the possibility to implement a
parallel planner in a multithread way, and the replies were that the
proposed approach couldn't be implemented, because the postgres is not
thread-safe. With the new fea
On 2013-02-10 16:03, Andrew Dunstan wrote:
On 02/10/2013 05:43 AM, Yeb Havinga wrote:
3. I was wondering how to access the first author from this json
snippet:
{
"id": "QZr82w_eSi8C",
"etag": "KZ+JsrkCdqw",
"volumeInfo": {
"title&quo
irst
element from the author array, and the function call does not need to be
changed when path lenghts change.
My apologies if this has been discussed before - I've gone through
threads from nov 2012 but did not find a previous discussion about this
topic.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2012-12-19 18:25, Robert Haas wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
postgres=> INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres=> INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation "t1" violates row-secirity
DETAIL: Failing row contains (5, eee).
I've a
than they currently have, and would
also encourage reuse of distributed nextval implementations.
regards,
Yeb
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2012-05-30 21:26, Kohei KaiGai wrote:
If we would have an "ideal optimizer", I'd still like the optimizer to
wipe out redundant clauses transparently, rather than RLSBYPASS
permissions, because it just controls all-or-nothing stuff.
For example, if tuples are categorized to unclassified, class
On 2012-04-04 17:10, Tom Lane wrote:
Yeb Havinga writes:
Using a cursor argument name equal to another plpgsql variable results
in the error:
cursor .. has no argument named ""
I think a better way would be to temporarily set
plpgsql_IdentifierLookup to IDENTIFIER_LOOKUP_DECLARE
instead of
yylex() by read_cursor_args when reading the argument name, and would
always return the argument name in yylval.str.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
>From 47c451cbf188ac2aff9784bff73bc7fb7b846d26 Mon Sep 17 00:00:00 2001
From: Willem & Yeb
Date: Wed, 4
When building a minimal PostgreSQL under the latest mingw (2018),
make check will give a few dozen fails with the server exiting on code
2. The build is fine when -O2 is removed from the CFLAGS. This behaviour
is present on all revs on the REL9_1_STABLE branch that I tested, among
which wer
in
+at their option, rather than (as in the case of a trusted procedure)
+as mandated by the system.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gating restrictions on a append rel child member to other areas
of the plan can cause unwanted results, like the ones currently seen?
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2012-03-11 11:33, Yeb Havinga wrote:
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with
added documentation.
s/cube(1) == '(1)'// in that patch please
--
Sent via pgsql-hackers ma
. Maybe this could be a leftover from
the initial implementation as GUC variable?
- earlier I suggested preventing setting a new client label from a
trusted procedure, however I just read in the original post that this
was how the current usecase of Joshua is set up. Suggestion withdrawn.
--
Yeb
On 2012-03-10 14:06, Robert Haas wrote:
On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga wrote:
As a separate but related note, the label management here seems to be
excessively complicated. In particular, it seems to me that the
semantics of sepgsql_get_client_label() become quite muddled under
bump in
sepgsql-regtest.te and to describe the actual feature.
I can probably write some docs tomorrow.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ction just appends to
the list, always. That the list is reset on transaction commit/abort
time, is done and also already documented elsewhere. A new reader could
be confused to not find transaction related things in
sepgsql_set_client_label().
regards,
Yeb
--
Yeb Havinga
http://www.mgrid.net/
On 2012-02-24 17:25, Yeb Havinga wrote:
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havinga:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to
label.c
because of references to static variables. The part-2 patch
implements
On 2012-02-27 12:49, Asif Rehman wrote:
Hi Yeb Havinga,
I was digging archives to see anyone worked on supporting domain's
over composite type and found your patch, but that was pulled back.
According to commitfest comments it needs some more work...
There were some issues with usin
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havinga:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.
I took a short look at
On 2012-02-24 15:17, Yeb Havinga wrote:
I don't know what's fishy about the mgrid user and root that causes
c0.c1023 to be absent.
more info:
In shells started in a x environment under Xvnc, id -Z shows the
system_u and c0.c1023 absent.
In shells started from the ssh daemon,
s virtual machine.
After setting the user "mgrid" on s0-s0:c0.c1023 with
semanage login -a -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 mgrid
the regression tests pass :-)
test label... ok
test dml ... ok
test create
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havinga:
So maybe this is because my start domain is not s0-s0:c0.c1023
However, when trying to run bash or psql in domain
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 I get permission
denied.
Distribution is FC15, sestatus
enforcing
Policy version: 24
Policy from config file:targeted
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2012-02-20 06:37, Don Baccus wrote:
On Feb 19, 2012, at 7:24 PM, Tom Lane wrote:
It's not clear to me whether pure/leakproof functions are meant to be a
strict subset of immutable functions
Superset, not subset, unless my guessing is wrong. How could "pure" be a subset of
"immutable"?
If
o
not the intended behaviour to support repeatable client_label switches.
"However, single-directed domain transition from bigger-privileges to
smaller-privileged domain by users' operation is also supported on
operating system, and useful feature to restrict applications capability
a
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to succeed. This would
cceed. This would also be
useful in conjunction with a connection pooler. This would still allow
the option to prevent a back transition to non-default client labels.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2012-01-13 21:14, Frederico wrote:
Hi folks.
Is there any restriction in create and start threads inside Postgres?
I'm trying to develop a multithread planner, and some times is raised a
exception of access memory.
I'm debugging the code to see if is a bug in the planner, but until now, I
uot;;
ERROR: invalid input syntax for integer: "2011-11-29 19:26:10.029084"
CONTEXT: PL/pgSQL function "namedparmcursor_test1" line 8 at OPEN
regards,
Yeb Havinga
last error was created with
create or replace function namedparmcursor_test1(int, int) returns
boolean as $$
t be reflected by
adding to the 'usage_privileges' section a link back to the
'udt_privileges' section.
I have no further comments on this patch.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2011-12-11 16:26, Yeb Havinga wrote:
On 2011-12-06 17:58, Kevin Grittner wrote:
Kevin Grittner wrote:
Yeb Havinga wrote:
I personally tend to believe it doesn't even need to be an error.
There is no technical reason not to allow it. All the user needs
to do is make sure tha
On 2011-12-06 17:58, Kevin Grittner wrote:
Kevin Grittner wrote:
Yeb Havinga wrote:
I personally tend to believe it doesn't even need to be an error.
There is no technical reason not to allow it. All the user needs
to do is make sure that the combination of named parameters an
lic;
REVOKE
postgres=# \c - c
You are now connected to database "postgres" as user "c".
postgres=> select udt_name,attribute_name from
information_schema.attributes;
udt_name | attribute_name
--+
t| a
(1 row)
postgres=> create table m2 (a
On 2011-12-06 17:58, Kevin Grittner wrote:
Kevin Grittner wrote:
If there are no objections, I suggest that Yeb implement the mixed
notation for cursor parameters.
Hearing no objections -- Yeb, are you OK with doing this, and do you
feel this is doable for this CF?
It is not a large change,
DDITIONAL TESTS, though I kept the
tests between those to comments.
The way this parses out the named parameters and then builds the
positional list, with some code from read_sql_construct() repeated in
read_cursor_args() seems a little bit clumsy to me, but I couldn't
think of a better wa
On 2011-12-01 22:14, Peter Eisentraut wrote:
On tor, 2011-12-01 at 14:37 +0100, Yeb Havinga wrote:
On 2011-11-29 18:47, Peter Eisentraut wrote:
On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote:
On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote:
On 2011-11-15 21:50, Peter
On 2011-11-29 18:47, Peter Eisentraut wrote:
On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote:
On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote:
On 2011-11-15 21:50, Peter Eisentraut wrote:
Patch attached.
I cannot get the patch to apply, this is the output of patch -p1
--dry
ither
commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252
Author: Heikki Linnakangas
Date: Thu Nov 3 13:16:28 2011 +0200
Support range data types.
and that's strange since git log of pg_type.h shows a commit of april
before that.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgs
On 2011-11-16 15:34, Tom Lane wrote:
Robert Haas writes:
Not sure about the log line, but allowing pgstattuple to distinguish
between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though. pgstattuple's idea of
RecentGlobalXmin could even be sig
of tuple counters should match in terminology and
actual values. Maybe also if pgstattuple were to include the distinction
unremovable dead tuples vs dead tuples, a log line by vacuum
encountering unremovable dead tuples could refer to pgstattuple for
statistics.
regards,
Yeb Havinga
--
Sen
On 2011-11-15 16:16, Robert Haas wrote:
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga wrote:
I reviewed your patch. I think it is in good shape, my two main remarks
(name of n_unremovable_tup and a remark about documentation at the end of
this review) are highly subjective and I wouldn't
re tuples that are deleted or previous versions of updated
tuples, and that only analyze updates n_dead_tup (since vacuum cleans
them), in contrast with n_unremovable_tup that gets updated by vacuum.
Giving an example of how unremovable dead tuples can be caused would
IMHO also help understa
On 2011-11-14 15:45, Yeb Havinga wrote:
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
T
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
Thanks again for the review and comments. Att
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
Tom, thanks for reviewing - getting the s
pgsql-cursors.html
Other than that, I think the patch is good. Everything works as advertised =)
Thanks!
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On 2011-10-07 12:21, Yeb Havinga wrote:
On 2011-10-06 16:04, Royce Ausburn wrote:
Initial Review for patch:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00744.php
Again, thank you very much for your thorough review. I'll update the
patch so mixing positional and named param
med parameters are removed, add
documentation, and give syntax errors before an error message indicating
that positional and named parameters were mixed.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2011-09-23 14:19, Heikki Linnakangas wrote:
On 23.09.2011 14:56, Yeb Havinga wrote:
I have a use case where an extension dependency can be satisfied by one
of five other extensions. Currently I'm unable to express that in the
extension control file, since the elements from 'req
b2008
vocab2009
vocab2010
thoughts?
regards,
Yeb Havinga
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
new file mode 100644
index 278bbcf..5bf7f8e
*** a/src/backend/commands/extension.c
--- b/src/bac
On 2011-09-15 16:31, Cédric Villemain wrote:
There exist also a mecanism to order the parameters of 'EXECUTE ...
USING ...' (it's using a cursor), can the current work benefit to
EXECUTE USING to use named parameters ?
I looked at it a bit but it seems there is no benefit, since the dynamic
e with => and then one with := notation.
Attached is the patch with := notation.
Is it ok to add it to the next commitfest?
regards,
Yeb Havinga, Willem Dijkstra
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
diff --git a/src/pl/plpgsql/src/gram.y b/src/pl/plpgsql/src/gram.y
new
On 2011-09-07 16:02, Kevin Grittner wrote:
Robert Haas wrote:
Anyone else want to bikeshed?
I'm not sure they beat TRUSTED, but:
SECURE
OPAQUE
SAVE
-- Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On 2011-09-06 04:55, Robert Haas wrote:
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
I didn't see my name as one of the reviewers in the commit m
t see my name as one of the reviewers in the commit message. If
that is because the review was bad, I'd be interested to know what I can
improve for the next one.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
everything in the query, except constants (and whitespace), so it would
be the same for all the queries Robert described. That could be low cost
enough to detect of for a query's id a cached plan exists and do more
work only in those cases.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Me
On 2011-07-27 16:16, Robert Haas wrote:
On Tue, Jul 26, 2011 at 5:37 PM, Tom Lane wrote:
Yeb Havinga writes:
A few days ago I read Tomas Vondra's blog post about dss tpc-h queries
on PostgreSQL at
http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in
which he showed h
On 2011-07-22 17:35, Hitoshi Harada wrote:
2011/7/23 Yeb Havinga:
Works like a charm :-). However, now there is always a copyObject of a
subquery even when the subquery is not safe for qual pushdown. The problem
with the previous issafe was that it was only assigned for
rel->baserestricti
ase of unsafe queries.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
new file mode 100644
index b5be09a..6596a1c
*** a/src/backend/nodes/outfuncs.c
--- b/src/backend/nodes/outfuncs.c
**
=277)
Sort Key: size_l.m_id
-> Seq Scan on size_l (cost=0.00..9829.00 rows=20
width=277)
I double checked that I had applied the patch (git diff shows the
patch), installed and restarted postgres. The database is a fresh
created database with no edits in postgresql.
y "unlabeled". I moved this to
sepgsql_avc_lookup itself.
2) Also I thought if it could work to not remember tcontext is valid,
but instead remember the consequence, which is that it is replaced by
"unlabeled". It makes the avc_cache struct shorter and the code somewhat
simpler.
regard
nd I think that the patch in it's current
status is ready for committer.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with
standard configurations, but that's also true for e.g. the block size.
Also, the tests I did with varying bucket sizes suggested that
decreasing the syscache to 2
On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga wrote:
Besides that I have to admit having problems understanding why the 5MB cache
for pg_seclabel is a problem; it's memory consumption is lineair only to the
size of the underlying database. (in con
ortional to the
number of objects in a database and in size it seems to be in the same
order as pg_proc, pg_class and pg_attribute.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 2011-07-20 16:54, Robert Haas wrote:
As to the first point, the other big problem with adding a syscache
here is that it could get really big. I've worried about that issue
previously, and Yev's perplexity about where the memory is going is
not too reassuring.
Yeah I just realized that #buck
On 2011-07-20 16:15, Yeb Havinga wrote:
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in
question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not
about
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not about
access rules to views, since it was mention
s guc?
* avc_init has magic numbers 384, 4096. Maybe these can be defines (with
a small comment what it is?)
* Finally, IMO the call sites, e.g. check_relation_priviliges, have
improved in readability with this patch.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via p
code that might introduce another leak path.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2011-07-19 22:39, Heikki Linnakangas wrote:
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is
On 2011-07-18 21:59, Robert Haas wrote:
There are only two patches left and I think we really ought to try to
take a crack at doing something with them. Yeb is working on the
userspace access vector cache patch, which I think is going drag on
longer than we want keep the CommitFest open, but I'm
On 2011-07-19 12:10, Kohei Kaigai wrote:
See the attached patch, that contains other 3 documentation updates.
I looked at the patch and the additions look good, though I didn't
actually apply it yet.
thanks
Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
o run regression test
without any modification of the default security policy.
Thank you for this clarification. I have some ideas of things that if
they were in the documentation they'd helped me. Instead of seeking
agreement on each item, I propose that I gather documentation additions
hat is their meaning? Can I define my own?
3) In the examples so far I've seen unconfined_u and system_u? Can I
define my own?
Thanks,
Yeb Havinga
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached rev
important new features of PostgreSQL and that
I want to commit myself to spend more community work on this subject.
regards,
Yeb
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2011-07-14 02:42, Josh Berkus wrote:
The first two are difficult patches, but the other two are not. Please
volunteer to give these patches a review; we owe it to our contributors
to review everything before the end of the CF.
When is the end of the CF? (I'm strongly suspecting today, but hav
On 2011-07-09 16:23, Hitoshi Harada wrote:
2011/7/5 Hitoshi Harada:
2011/7/5 Yeb Havinga:
Hello Hitosh, list,
Attached is revised version.
I failed to attached the patch. I'm trying again.
I'm currently unable to test, since on holiday. I'm happy to continue
testing once
Hello Hitosh, list,
>
> > Attached is revised version.
>
> I failed to attached the patch. I'm trying again.
>
> I'm currently unable to test, since on holiday. I'm happy to continue
testing once returned but it may not be within the bounds of the current
commitfest, sorry.
> >> 5) Regression te
On 2011-06-30 09:39, Yeb Havinga wrote:
9) as remarked up a different thread, more than one clause could be
pushed down a subquery. The current patch only considers alternative
paths that have at most one clause pushed down. Is this because of the
call site of best_inner_subqueryscan, i.e
use cases for this patch.
I think the most important thing for this patch to go forward is to have
a few examples, from which it's clear that the patch is beneficial.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list
1 - 100 of 240 matches
Mail list logo
