Re: [HACKERS] Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
On 31/05/10 18:14, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: The central question is whether checkpoint_segments should trigger restartpoints or not. When PITR and restartpoints were introduced, the answer was no, on the grounds that when you're doing recovery you're presumably replaying the logs much faster than they were generated, and you don't want to slow down the recovery by checkpointing too often. Now that we have bgwriter active during recovery, and streaming replication which retains the streamed WALs so that we now risk running out of disk space with long checkpoint_timeout, it's time to reconsider that. I think we have three options: What about (4) pay some attention to the actual elapsed time since the last restart point? All the others seem like kluges that are relying on hard-wired rules that are hoped to achieve something like a time-based checkpoint. Huh? We already do time-based restartpoints, there's nothing wrong with that logic AFAIK. The problem that started this thread is that we don't do WAL-space consumption based restartpoints, i.e. checkpoint_segments does nothing in standby mode. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Index only scans
On 31/05/10 18:09, Shrish Purohit wrote: Sometime back you have started with Separate Heap Fetch from Index Scan which was planned to support partial index only scans. Are you still working on it or do you know someone still working on it? I'm not working on it right now, but hopefully I'll have the time to revisit that for 9.1. If anyone else wants to pick it up, be my guest, I'll be glad to review and join the discussions. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] What the function name to get the contents table/tuple ?
Using this code below (particularly heap_open) somehow i can fetch all
table column name, and put in on list of string. Before raw_parsetree is
processed by analyze part.
--start code
-
RangeVar *relation = makeNode(RangeVar);
relation-schemaname = NULL;
relation-catalogname = NULL;
relation-relname = pg_class; //table name
relation-inhOpt = INH_DEFAULT;
relation-istemp = false ;
relation-alias = NULL;
Relation Rel;
LOCKMODElockmode = AccessShareLock;
Rel = heap_open(TableSpaceRelationId,lockmode);
Value *attrname ;
TupleDesc td;
td = Rel-rd_att;
List*colnames;
colnames = NIL;
int z;
int maxatribut = td-natts;
Form_pg_attribute fpa;
for (z=0;zmaxatribut;z++)
{
fpa = td-attrs[z];
attrname = makeString(pstrdup(NameStr(fpa-attname)));
colnames = lappend(colnames,attrname); //this where list cols name
colected
}
--end code
-
My question, is there same kind function that i can use to get table
content (tuple)?
Thank You.
--
Mohammad Heykal Abdillah heykal.abdil...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
As it was reported before, we have an open item about leaky VIEWs for RLS. On the talk at Ottawa, Robert suggested me to post my idea prior to submit a patch. So, I'd like to explain my idea at first. Actually I'm not familiar to optimizar details, so it needs any helps from experts of optimizar. The problem was ... * Using views for row-level access control is leaky http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php Even if a table is unvisible from certain users without views that filter a part of tuples, it can leak to users as long as they can define their own functions. It seems to me the problem can be divided into two major parts. See the following sample tables, views and functions. postgres=# CREATE TABLE t1 (a int primary key, b text); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index t1_pkey for table t1 CREATE TABLE postgres=# CREATE TABLE t2 (x int primary key, y text); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index t2_pkey for table t2 CREATE TABLE postgres=# INSERT INTO t1 VALUES (1, 'aaa'), (2, 'bbb'), (3, 'ccc'); INSERT 0 3 postgres=# INSERT INTO t2 VALUES (1, 'xxx'), (2, 'yyy'), (3, 'zzz'); INSERT 0 3 -- We assume the security policy function needs the given integer key -- is odd number to be visible for users. -- postgres=# CREATE OR REPLACE FUNCTION f_policy(int) RETURNS bool AS 'BEGIN RETURN $1 % 2 = 1; END' LANGUAGE plpgsql; CREATE FUNCTION -- We assume a malicious user defined function raises a notice with -- given arguments. It may be possible to insert it other temp tables. -- postgres=# CREATE OR REPLACE FUNCTION f_malicious(text) RETURNS bool COST 0.0001 AS 'BEGIN RAISE NOTICE ''f_malicious: %'', $1; RETURN true; END;' LANGUAGE plpgsql; CREATE FUNCTION [1] The order of scan filters to be evaluated -- The first problem is an inversion of evaluation of scan filters. postgres=# CREATE OR REPLACE VIEW v1 AS SELECT * FROM t1 WHERE f_policy(a); CREATE VIEW postgres=# EXPLAIN SELECT * FROM v1 WHERE f_malicious(b); QUERY PLAN --- Seq Scan on t1 (cost=0.00..329.80 rows=137 width=36) Filter: (f_malicious(b) AND f_policy(a)) (2 rows) postgres=# SELECT * FROM v1 WHERE f_malicious(b); NOTICE: f_malicious: aaa NOTICE: f_malicious: bbb -- leaky contents NOTICE: f_malicious: ccc a | b ---+- 1 | aaa 3 | ccc (2 rows) In this case, owner of the view expects tuples within t1 shall be filtered by f_policy() functions, so tuples with even-number shall be invisible. However, the optimizar reorders evaluation of scan filters based on the cost parameter of functions and others, then f_malicious() was invoked prior to f_policy(). It is a right approach, if functions are not malicious. But user may define a malicious purpose function. The given query is internally rewritten, then subquery will be pulled up in the optimizar logic. SELECT * FROM v1 WHERE f_malicious(b); - SELECT * FROM (SELECT * FROM t1 WHERE f_policy(a)) v1 WHERE f_malicious(b) - SELECT * FROM t1 WHERE f_policy(a) AND f_malicious(b) During we create a scan plan, the order_qual_clauses() computes the best order to evaluate the given WHERE clause based on the cost estimation. In this case, f_malicious() has very small cost, so order_qual_clauses() decides the f_malicious() should be invoked earlier than f_policy(). In the result, ExecScan() invokes f_malicious() with contents of scanned tuples to be invisible. I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember where is originally put in the query, and prevent reordering over the nest level of subqueries. In above example, f_malicious() has nestlevel=0 because it is put on the top level. But f_policy() has nestlevel=1 because it is originally put on the second level subquery. Then, the order_qual_clauses() will check nestlevel of the scan filter prior to reorder them based on the cost estimation. Even if we have multiple nestlevels, solution will be same. A FuncExpr with larger nestlevel shall be invoked earlier than others. Please note that we only focus on user defined functions. For example, it is worth to choose index-scans instead of seq-scans, when a user provides conditions which can be indexed, as follows: SELECT * FROM v1 WHERE a = 100; - SELECT * FROM (SELECT * FROM t1 WHERE f_policy(a)) v1 WHERE a = 100; In this case, we should scan the t1 using index with the condition of 'a = 100' prior to evaluation of f_policy(). Any operators eventually invokes a function being correctly installed, but an assumption is that we can trust operators, index access method, type input/output methods, conversions and so on, because these features have to be installed by DBA (or initdb). [2] Unexpected distribution of scan filter
Re: [HACKERS] [BUGS] BUG #5487: dblink failed with 63 bytes connection names
On 01/06/10 05:55, Takahiro Itagaki wrote: Takahiro Itagakiitagaki.takah...@oss.ntt.co.jp wrote: Contib/dblink module seems to have a bug in handling connection names in NAMEDATALEN-1 bytes. Here is a patch to fix the bug. I think it comes from wrong usage of snprintf(NAMEDATALEN - 1). It just copies 62 bytes + \0. In addition, it should be safe to use pg_mbcliplen() to truncate extra bytes in connection names because we might return invalid text when a multibyte character is at 62 or 63 bytes. Hmm, seems that dblink should call truncate_identifier() for the truncation, to be consistent with truncation of table names etc. I also spotted this in dblink.c: /* first gather the server connstr options */ if (strlen(servername) NAMEDATALEN) foreign_server = GetForeignServerByName(servername, true); I think that's wrong. We normally consistently truncate identifiers at creation and at use, so that if you create an object with a very long name and it's truncated, you can still refer to it with the untruncated name because all such references are truncated too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On 01/06/10 11:39, KaiGai Kohei wrote: Any operators eventually invokes a function being correctly installed, but an assumption is that we can trust operators, index access method, type input/output methods, conversions and so on, because these features have to be installed by DBA (or initdb). Operators can be created by regular users. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On mån, 2010-05-31 at 18:23 -0400, Tom Lane wrote: My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. Given that Oracle and DB2 already support that syntax in released products, and I'm not even a member of any relevant body, that seems pretty much impossible. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keepalive for max_standby_delay
On 27/05/10 20:26, Simon Riggs wrote: On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote: Just this second posted about that, as it turns out. I have a v3 *almost* ready of the keepalive patch. It still makes sense to me after a few days reflection, so is worth discussion and review. In or out, I want this settled within a week. Definitely need some RR here. Does the keepalive fix all the issues with max_standby_delay? Tom? OK, here's v4. Summary * WALSender adds a timestamp onto the header of every WAL chunk sent. * Each WAL record now has a conceptual send timestamp that remains constant while that record is replayed. This is used as the basis from which max_standby_delay is calculated when required during replay. * Send timestamp is calculated as the later of the timestamp of chunk in which WAL record was sent and the latest XLog time. * WALSender sends an empty message as a keepalive when nothing else to send. (No longer a special message type for the keepalive). I think its close, but if there's a gaping hole here somewhere then I'll punt for this release. This certainly alleviates some of the problems. You still need to ensure that master and standby have synchronized clocks, and you still get zero grace time after a long period of inactivity when not using streaming replication, however. Sending a keep-alive message every 100ms seems overly aggressive to me. If we really want to try to salvage max_standby_delay with a meaning similar to what it has now, I think we should go with the idea some people bashed around earlier and define the grace period as the difference between a WAL record becoming available to the standby for replay, and between replaying it. An approximation of that is to do lastIdle = gettimeofday() in XLogPageRead() whenever it needs to wait for new WAL to arrive, whether that's via streaming replication or by a success return code from restore_command, and compare the difference of that with current timestamp in WaitExceedsMaxStandbyDelay(). That's very simple, doesn't require synchronized clocks, and works the same with file- and stream-based setups. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
(2010/06/01 18:08), Heikki Linnakangas wrote: On 01/06/10 11:39, KaiGai Kohei wrote: Any operators eventually invokes a function being correctly installed, but an assumption is that we can trust operators, index access method, type input/output methods, conversions and so on, because these features have to be installed by DBA (or initdb). Operators can be created by regular users. Oops, I missed it. Indeed, operator function is not limited to C-language functions, so regular users can create it. Apart from the topic, does it seem to you reasonable direction to tackle to the leaky VIEWs problem? Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On 01/06/10 13:04, KaiGai Kohei wrote: Oops, I missed it. Indeed, operator function is not limited to C-language functions, so regular users can create it. Apart from the topic, does it seem to you reasonable direction to tackle to the leaky VIEWs problem? Yeah, I guess it is. The general problem is that it seems like a nightmare to maintain this throughout the planner. Who knows what optimizations this affects, and do we need to hide things like row-counts in EXPLAIN output? If we try to be very strict, we can expect a stream of CVEs and security releases in the future while we find holes and plug them. On the other hand, using views to restrict access to underlying tables is a very useful feature, so I'd hate to just give up. We need to decide what level of isolation we try to accomplish. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keepalive for max_standby_delay
Thanks for the review. On Tue, 2010-06-01 at 13:36 +0300, Heikki Linnakangas wrote: If we really want to try to salvage max_standby_delay with a meaning similar to what it has now, I think we should go with the idea some people bashed around earlier and define the grace period as the difference between a WAL record becoming available to the standby for replay, and between replaying it. An approximation of that is to do lastIdle = gettimeofday() in XLogPageRead() whenever it needs to wait for new WAL to arrive, whether that's via streaming replication or by a success return code from restore_command, and compare the difference of that with current timestamp in WaitExceedsMaxStandbyDelay(). That wouldn't cope with a continuous stream of records arriving, unless you also include the second half of the patch. That's very simple, doesn't require synchronized clocks, and works the same with file- and stream-based setups. Nor does it provide a mechanism for monitoring of SR. standby_delay is explicitly defined in terms of the gap between two servers, so is a useful real world concept. apply_delay is somewhat less interesting. I'm sure most people would rather have monitoring and therefore the requirement for synchronised-ish clocks, than no monitoring. If you think no monitoring is OK, I don't, but there are other ways, so its not a point to fight about. This certainly alleviates some of the problems. You still need to ensure that master and standby have synchronized clocks, and you still get zero grace time after a long period of inactivity when not using streaming replication, however. Second issue can be added once we approve the rest of this if you like. Sending a keep-alive message every 100ms seems overly aggressive to me. It's sent every wal_sender_delay. Why is that a negative? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Trigger function in a multi-threaded environment behavior
We have a multi-threaded environment in linux where multiple threads are performing database operations(insert, update, select and at times delete as well) in transaction mode (which may span across stored procedures) using unixodbc. Now this as is, works fine. If we introduce postgres triggers (trigger functions) on some of the tables to track insert/update/delete operations, (This is done by keeping and updating a counter field for every insert, update and delete operation performed on a set of tables inside trigger function) at this point, one or more threads get stuck in lock while executing the query, to the extent that sometimes even with the pgadmin, the database tables cannot be updated. We are using postgres v8.4 and unixodbc v2.2.14. Here in this case when using postgres triggers in a multithreaded application, do we have to take care of table/row level locks inside trigger function. Thanks, Hardik
Re: [HACKERS] Trigger function in a multi-threaded environment behavior
On tis, 2010-06-01 at 16:40 +0530, Hardik Belani wrote: If we introduce postgres triggers (trigger functions) on some of the tables to track insert/update/delete operations, (This is done by keeping and updating a counter field for every insert, update and delete operation performed on a set of tables inside trigger function) at this point, one or more threads get stuck in lock while executing the query, to the extent that sometimes even with the pgadmin, the database tables cannot be updated. You should be able to analyze the lock situation using the views pg_locks and pg_stat_activity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Jun 1, 2010, at 10:39 , KaiGai Kohei wrote: I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember where is originally put in the query, and prevent reordering over the nest level of subqueries. In above example, f_malicious() has nestlevel=0 because it is put on the top level. But f_policy() has nestlevel=1 because it is originally put on the second level subquery. Then, the order_qual_clauses() will check nestlevel of the scan filter prior to reorder them based on the cost estimation. Even if we have multiple nestlevels, solution will be same. A FuncExpr with larger nestlevel shall be invoked earlier than others. Wouldn't the information leak go away if you stuck OFFSET 0 at the end of the view? IIRC, that is the semi-offical way to create barriers for subquery flattening and such. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
2010/6/1 KaiGai Kohei kai...@ak.jp.nec.com: I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember where is originally put in the query, and prevent reordering over the nest level of subqueries. In above example, f_malicious() has nestlevel=0 because it is put on the top level. But f_policy() has nestlevel=1 because it is originally put on the second level subquery. Then, the order_qual_clauses() will check nestlevel of the scan filter prior to reorder them based on the cost estimation. Even if we have multiple nestlevels, solution will be same. A FuncExpr with larger nestlevel shall be invoked earlier than others. [...] My idea is similar to what I proposed at [1]. It adds a new field into RelOptInfo (or other structure?) to remember the original nestlevel of the scan, then it will be compared to nestlevel of the FuncExpr. If nestlevel of the FuncExpr is smaller than nestlevel of the RelOptInfo, it prevents to distribute the FuncExpr onto the RelOptInfo, even if the function depends on only the relation of RelOptInfo. Keep in mind that users who are NOT using a view as a security barrier don't expect it to kill performance. This approach, and particularly the second part, about preventing quals from being pushed through joins, has the potential to be a performance disaster. So I think it's absolutely critical that we don't do that except when it's necessary to prevent a security issue. On the technical side, I am pretty doubtful that the approach of adding a nestlevel to FuncExpr and RelOptInfo is the right way to go. I believe we have existing code (to handle left joins) that prevents quals from being pushed down too far by fudging the set of relations that are supposedly needed to evaluate the qual. I suspect a similar approach would work here. I think the steps here are: 1. Decide whether the view is a security barrier (perhaps, check whether the user has sufficient privs to execute the underlying query; or we could add an explicit setting). If not, stop. 2. Decide whether each qual executes potentially untrusted code (algorithm?). 3. Prevent any untrusted quals from being pushed down into view that is a security barrier. We should have a design for each of these before we start coding. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
2010/6/1 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: On 01/06/10 11:39, KaiGai Kohei wrote: Any operators eventually invokes a function being correctly installed, but an assumption is that we can trust operators, index access method, type input/output methods, conversions and so on, because these features have to be installed by DBA (or initdb). Operators can be created by regular users. So I think we don't actually have to worry about operators and functions which allow us to use an index scan. If they're used in an index definition then the definer of those functions can see the entire table anyways. The only place where this matters, at least to a first degree, is on the filter operations applied to a scan. If the view isn't owned by the current user then all the filters of the view have to be enforced first then the query filters. Heikki's point is still valid though. Consider if it's not a matter of filter ordering but rather that a filter is being pushed down inside a join. If the join is from the view then it would be unsafe to filter the rows before seeing which rows match the join... unless we can prove all the rows survive... It would really suck not to do this optimization too if for example you have a filter which filters all but a single row and then join against a large table... -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
2010/6/1 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: The general problem is that it seems like a nightmare to maintain this throughout the planner. Who knows what optimizations this affects, and do we need to hide things like row-counts in EXPLAIN output? If we try to be very strict, we can expect a stream of CVEs and security releases in the future while we find holes and plug them. On the other hand, using views to restrict access to underlying tables is a very useful feature, so I'd hate to just give up. We need to decide what level of isolation we try to accomplish. I'm entirely uninspired by the idea of trying to prevent all possible leakage of information via side-channels. Even if we tried to obfuscate the explain output, the user can still potentially get some information by timing how long queries take to execute. I think if we have a hook function that can prevent certain users from running EXPLAIN altogether (and I believe this may already be the case) that's about the appropriate level of worrying about that case. I think the only thing that we can realistically prevent is allowing users to make off with the actual tuples. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Giles Lean wrote: Bruce Momjian br...@momjian.us wrote: is_relative_to_cwd()? ../../../../some/other/place/not/under/cwd Names are hard, but if I understood the original post, the revised function is intended to check that the directory is below the current working directory. We check for things like .. other places, though we could roll that into the macro if we wanted. Because we are adding a new function, that might make sense. If my understanding is wrong (always possible!) and it only has to be on the same drive, then your name is probably better although it doesn't mention 'drive' ... hrm. is_on_current_drive()? (Yuck.) is_on_current_filesystem()? (Yuck, but at least more general.) I think we (or at least I) need some clarification from the original poster about what the code is checking for in detail. I think you have to look at all the reference to is_absolute_path() in the C code. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Trigger function in a multi-threaded environment behavior
On Tue, Jun 1, 2010 at 7:10 AM, Hardik Belani hardikbel...@gmail.com wrote: If we introduce postgres triggers (trigger functions) on some of the tables to track insert/update/delete operations, (This is done by keeping and updating a counter field for every insert, update and delete operation performed on a set of tables inside trigger function) at this point, one or more threads get stuck in lock while executing the query, to the extent that sometimes even with the pgadmin, the database tables cannot be updated. Well, if you have a lot of concurrent backends trying to update the same counters, it is pretty reasonable to think that you're going to have some lock contention. There are a variety of ways to work around this - insert rows (instead of updating) and summarize them later, write the data to a flatfile somewhere and summarize it later, use the built-in statistics mechanisms, etc. Fundamentally the problem is that if transaction A is adding 1 to a counter and transaction B is adding 1 to a counter, one must wait for the other to commit. If A gets there first and updates the counter from, say, 37 to 38, B has to wait to see whether A commits or aborts. If A aborts, B must add 1 to 37; if A commits, B must add 1 to 38. Until A commits or aborts, B doesn't know what value it's adding 1 *to*. So every transaction updating that counter serializes on the counter itself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Bruce Momjian br...@momjian.us writes: Giles Lean wrote: Names are hard, but if I understood the original post, the revised function is intended to check that the directory is below the current working directory. We check for things like .. other places, though we could roll that into the macro if we wanted. Because we are adding a new function, that might make sense. Yeah. If we were to go with Greg's suggestion of inventing a separate is_relative_to_cwd test function, I'd expect that to insist on no .. while it was at it. That seems like a fairly clean approach in the abstract, but I agree that somebody would have to look closely at each existing usage to be sure it works out well. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Andy Balholm a...@balholm.com wrote: On May 30, 2010, at 6:53 AM, Kevin Grittner wrote: You would then generate a diff in context format and post to the -hackers list with that file as an attachment. Here it is: [context diff attachment] I can't add it to the CommitFest page, since I don't have web access, just e-mail. Could you please take care of that part? Done. I'll keep it up-to-date as other posts occur. (What is the CommitFest page, anyway?) A CommitFest is a periodic break to PostgreSQL development that focuses on patch review and commit rather than new development. These are held so that all the work for a release gets relatively prompt review and feedback, and so that work for a release doesn't pile up until the end of the release cycle. During these periods developers are asked to review and test the patches submitted by others. The hope is that this will also reduce the burden on those who do the final review and commit. The CF page is used to keep track of submitted patches and their status, to help manage the process. When we're not trying to put together a major release CFs tend to run for one month each with a one month gap between them. Due to the process of getting a release out the door, though, the last one started on the 15th of January and the next one starts on the 15th of July. We're going to try to get some early review on as many patches as possible starting the 15th of June, but the committers probably won't have much time to deal with any of this until the official CF, so we're calling this (less formal) period a Review Fest. The peer review process often results in discussion on the -hackers list and/or requests for some sort of modification before commit. Most patches wind up getting committed, although some are returned with feedback (in hopes that the submitter will make some change and submit to a later cycle) or rejected (if they are determined by the community not to be useful changes). By the way, I signed on to review your patch. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Thanks for the explanation of CommitFests. On May 30, 2010, at 6:53 AM, Kevin Grittner wrote: You would then generate a diff in context format and post to the -hackers list with that file as an attachment. I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. But using git diff would be less hassle. Do the diffs from git diff work just as well? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
Greg Stark gsst...@mit.edu writes: Heikki's point is still valid though. Consider if it's not a matter of filter ordering but rather that a filter is being pushed down inside a join. If the join is from the view then it would be unsafe to filter the rows before seeing which rows match the join... unless we can prove all the rows survive... It would really suck not to do this optimization too if for example you have a filter which filters all but a single row and then join against a large table... Well, more generally, any restriction whatsoever that is placed on the current planner behavior in the name of security will result in catastrophic performance degradation for some queries. I agree with Robert's nearby comments that we need to be selective about which views we do this to and which functions we distrust. CREATE SECURITY VIEW, anyone? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Andy Balholm wrote: Thanks for the explanation of CommitFests. On May 30, 2010, at 6:53 AM, Kevin Grittner wrote: You would then generate a diff in context format and post to the -hackers list with that file as an attachment. I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. But using git diff would be less hassle. Do the diffs from git diff work just as well? Yes, of course. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Andy Balholm wrote: Thanks for the explanation of CommitFests. On May 30, 2010, at 6:53 AM, Kevin Grittner wrote: You would then generate a diff in context format and post to the -hackers list with that file as an attachment. I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. But using git diff would be less hassle. Do the diffs from git diff work just as well? context diffs are preferred - for advise on how to create them: http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exposing the Xact commit order to the user
On 5/28/2010 7:19 PM, Bruce Momjian wrote: Jan Wieck wrote: Reading the entire WAL just to find all COMMIT records, then go back to the origin database to get the actual replication log you're looking for is simpler and more efficient? I don't think so. Agreed, but I think I've not explained myself well enough. I proposed two completely separate ideas; the first one was this: If you must get commit order, get it from WAL on *origin*, using exact same code that current WALSender provides, plus some logic to read through the WAL records and extract commit/aborts. That seems much simpler than the proposal you outlined and as SR shows, its low latency as well since commits write to WAL. No need to generate event ticks either, just use XLogRecPtrs as WALSender already does. I see no problem with integrating that into core, technically or philosophically. Which means that if I want to allow a consumer of that commit order data to go offline for three days or so to replicate the 5 requested, low volume tables, the origin needs to hang on to the entire WAL log from all 100 other high volume tables? I suggest writing an external tool that strips out what you need that can be run at any time, rather than creating a new data format and overhead for this usecase. Stripping it out from what? Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exposing the Xact commit order to the user
Jan Wieck wrote: I see no problem with integrating that into core, technically or philosophically. Which means that if I want to allow a consumer of that commit order data to go offline for three days or so to replicate the 5 requested, low volume tables, the origin needs to hang on to the entire WAL log from all 100 other high volume tables? I suggest writing an external tool that strips out what you need that can be run at any time, rather than creating a new data format and overhead for this usecase. Stripping it out from what? Stripping it from the WAL. Your system seems to require double-writes on a commit, which is something we have avoided in the past. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Andy Balholm a...@balholm.com wrote: I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. But using git diff would be less hassle. Do the diffs from git diff work just as well? I agree about the git diff being easier; however, those files are in unified format and some committers prefer to read the context format, so I'd recommend piping it through filterdiff --format=context. Personally, although I submit patches in context format, I keep the unified copy around because I find the method names from git useful and I like to be able to view the patch through kompare, which doesn't seem to like the context format as well. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] VACUUM messages without newlines
This has annoyed me for some time, but it appears that in the VACUUM log, the line which says... INFO: analyzing %s.%s ...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and 287 ) doesn't terminate with a newline, meaning the next message appears immediately after it. Either the errmsg function should be doing this, or should be included explicitly in the message itself as it does with all other messages output to VACUUM logs. The same goes for... CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec ... as appearing in pgsql/src/backend/utils/misc/pg_rusage.c (line 64) and %s: scanned %d of %u pages, containing %.0f live rows and %.0f dead rows; %d rows in sample, %.0f estimated total rows ... in pgsql/src/backend/commands/analyze.c (line 1220). Could this be changed, or is there a reason these have to be logged this way? Thanks Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010: This has annoyed me for some time, but it appears that in the VACUUM log, the line which says... INFO: analyzing %s.%s ...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and 287 ) doesn't terminate with a newline, meaning the next message appears immediately after it. The message pieces are sent separately. They are only crammed in a single line if the interface is using the old mechanism to extract error message info; anything built after cca. 2002 should be reading fields separately, and printing them in separate lines. The same goes for... CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec Now you can argue that this line is too long, but that's a different problem than the one above. %s: scanned %d of %u pages, containing %.0f live rows and %.0f dead rows; %d rows in sample, %.0f estimated total rows This too. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Excerpts from Kevin Grittner's message of mar jun 01 11:09:38 -0400 2010: I agree about the git diff being easier; however, those files are in unified format and some committers prefer to read the context format, so I'd recommend piping it through filterdiff --format=context. Personally, although I submit patches in context format, I keep the unified copy around because I find the method names from git useful Hmm, cvs diff -Ncp does show method names too, so this is probably filterdiff removing them. BTW maybe the developer faq could use all the info gathered in this thread. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
On 1 June 2010 16:28, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010: This has annoyed me for some time, but it appears that in the VACUUM log, the line which says... INFO: analyzing %s.%s ...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and 287 ) doesn't terminate with a newline, meaning the next message appears immediately after it. The message pieces are sent separately. They are only crammed in a single line if the interface is using the old mechanism to extract error message info; anything built after cca. 2002 should be reading fields separately, and printing them in separate lines. I see what you mean. I'm seeing this in the latest version of pgAdmin III (1.10.3) so looks like it's not up-to-date in that respect. Should report it as a pgAdmin problem then? Thanks Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
Also incidentally I'm having trouble imagining a scenario where this really matters. For it to be an issue you would have to simultaneously have a user which can't access all the data and must go through views which limit the data he can access -- and has privileges to issue DDL to create functions and operators. That seems like an unlikely combination. I've seen views used before to restrict the role accounts used by front-end applications but those accounts have no DDL privileges. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Alvaro Herrera alvhe...@commandprompt.com wrote: Hmm, cvs diff -Ncp does show method names too, so this is probably filterdiff removing them. My bad; I apparently got confused somehow when looking at a context diff -- the function names are indeed there after the filterdiff conversion. Sorry for the noise on that. BTW maybe the developer faq could use all the info gathered in this thread. I'll take a look at that today. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
Thom Brown thombr...@gmail.com writes: I see what you mean. I'm seeing this in the latest version of pgAdmin III (1.10.3) so looks like it's not up-to-date in that respect. Should report it as a pgAdmin problem then? Yes. The message texts in ereport() calls are *not* supposed to have trailing newlines. If you don't like the way it's presented on the client side, that's a client-side problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
On 1 June 2010 16:50, Tom Lane t...@sss.pgh.pa.us wrote: Thom Brown thombr...@gmail.com writes: I see what you mean. I'm seeing this in the latest version of pgAdmin III (1.10.3) so looks like it's not up-to-date in that respect. Should report it as a pgAdmin problem then? Yes. The message texts in ereport() calls are *not* supposed to have trailing newlines. If you don't like the way it's presented on the client side, that's a client-side problem. regards, tom lane Yes, I can see that now. I'd looked up other messages which appear in the log and noticed they were terminated with newlines in the back-end, but I guess those were of a different type and happen to share the same output. Thanks Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
Excerpts from Thom Brown's message of mar jun 01 11:34:38 -0400 2010: On 1 June 2010 16:28, Alvaro Herrera alvhe...@commandprompt.com wrote: The message pieces are sent separately. They are only crammed in a single line if the interface is using the old mechanism to extract error message info; anything built after cca. 2002 should be reading fields separately, and printing them in separate lines. I see what you mean. I'm seeing this in the latest version of pgAdmin III (1.10.3) so looks like it's not up-to-date in that respect. Should report it as a pgAdmin problem then? Hmm, I wouldn't expect pgAdmin to behave this way. [ tests ... ] Hey, I see a problem here. After the last INFO message (which is not the same you mentioned, at least in this server version) my server crashed for whatever reason, and the error report for that got stuffed in the same line, and it didn't have the FATAL leader either. Pretty weird. I'm fairly sure this is pgAdmin's doing, 'cause psql doesn't behave this way. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] VACUUM messages without newlines
Thom Brown thombr...@gmail.com writes: Yes, I can see that now. I'd looked up other messages which appear in the log and noticed they were terminated with newlines in the back-end, but I guess those were of a different type and happen to share the same output. Hm, sure you're not thinking of frontend code? We generally do include trailing newlines in message texts on that side, but elog/ereport on the backend side should never have them. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Add XMLEXISTS function from the SQL/XML standard
Quoting Peter Eisentraut pete...@gmx.net:
It would be nice to make XMLEXISTS work as in the standard, seeing how
many others are providing the same interface.
...
I think providing XPath is enough, at least for now.
Hi Peter,
From piecing together sections 8.4 (XML exists predicate) and 6.18
(XML query), I believe the full call signature would be (apologies
if my bracketing isn't right):
XMLEXISTS
(
xquery_expression
[
PASSING {BY REF|BY VALUE}
{ (xml_expression [BY REF|BY VALUE])
| (xml_expression AS identifier)
}
[, ...]
]
)
Seeing as we're only intereseted in XPath for the moment and most of
the syntax above is only really relevant to XQuery, I would suggest
the following as accepatable until full XQuery support comes:
XMLEXISTS
(
xpath_expression
[
PASSING BY REF xml_expression [BY REF]
]
)
There is one drawback in this approach, namely xml namespace support.
I think borrowing the solution used in the xpath() (i.e. passing a
nsarray) is out of the question as it won't be future proofed against
full XQuery support. This is because the declaration of namespaces in
XQuery is actually part of the query itself. I also think it
inappropriate to attempt to parse the xpath_expression looking for
XQuery style namespace declartions. So I think we ignore declared
namespace support for the moment and just get the syntax correct ready
for XQuery support in the hopefully near future.
Do you agree with what I have proposed?
Regards,
--
Mike Fowler
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exposing the Xact commit order to the user
On 6/1/2010 11:09 AM, Bruce Momjian wrote: Jan Wieck wrote: I see no problem with integrating that into core, technically or philosophically. Which means that if I want to allow a consumer of that commit order data to go offline for three days or so to replicate the 5 requested, low volume tables, the origin needs to hang on to the entire WAL log from all 100 other high volume tables? I suggest writing an external tool that strips out what you need that can be run at any time, rather than creating a new data format and overhead for this usecase. Stripping it out from what? Stripping it from the WAL. Your system seems to require double-writes on a commit, which is something we have avoided in the past. Your suggestion seems is based on several false assumptions. This does neither require additional physical writes on commit, nor is consuming the entire WAL just to filter out commit records anything even remotely desirable for systems like Londiste or Slony. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] exporting raw parser
On 5/26/2010 10:16 PM, Tatsuo Ishii wrote: As was already discussed, I don't believe that premise. None of the applications you cite would be able to make use of the raw parser output, because it doesn't contain the semantic information they need. If what you actually meant was the analyzed parse tree, that *might* serve the need depending on just what is wanted (in particular, properties that could be affected by the expansion of views or inlineable functions could still not be determined reliably). But you can't have that without access to the current system catalog contents. No, what pgpoo-II needs is a raw parse tree. When it needs info in the system catalog, it sends SELECT to PostgreSQL. So that would be no problem. But doesn't it need that parse tree BEFORE it makes the decision, which node to execute the query on? The parser needs the system catalog in order to create a parse tree. Where would that stand-alone library version of the parser get the catalog information from? Don't you need to know which user defined function in the query is volatile? Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
* Greg Stark (gsst...@mit.edu) wrote: Also incidentally I'm having trouble imagining a scenario where this really matters. For it to be an issue you would have to simultaneously have a user which can't access all the data and must go through views which limit the data he can access -- and has privileges to issue DDL to create functions and operators. That seems like an unlikely combination. I've seen views used before to restrict the role accounts used by front-end applications but those accounts have no DDL privileges. Erm, I have to disagree with this in general.. We don't all just build web apps. On multi-user databases, this really isn't that uncommon. I'm not saying it's an everyday kind of thing, but I don't think this issue is something we can just ignore either. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. The only disadvantage to that approach that I see is that it introduces some extra permission-checking overhead. If having an explicit notion of which views are intended to be security views enables us to reduce or eliminate that overhead, it may be worth doing. But I'm not sure that it does. A blanket rule that says don't push untrusted quals into security views is not going to be too satisfactory - we probably want to do that only when the view is queried by an untrusted user - the superuser, or someone else with adequate permissions, will presumably still want his quals to get pushed down. Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
Robert Haas robertmh...@gmail.com writes: On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. Ummm ... that makes semantics dependent on the permissions available at plan time, whereas what should matter is the permissions that exist at execution time. Maybe that's all right for this context but it doesn't seem tremendously desirable. Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -1 on that. We will get far more pushback from people whose application performance suddenly went to hell than we will ever get approval from people who actually need the feature. Considering that we've survived this long with leaky views, that should definitely remain the default behavior. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. Ummm ... that makes semantics dependent on the permissions available at plan time, whereas what should matter is the permissions that exist at execution time. Maybe that's all right for this context but it doesn't seem tremendously desirable. Ugh. I hope there's a way around that problem because AFAICS the alternative is a world of hurt. If we're not allowed to take the security context into account during planning, then we're going to have to make worst-case assumptions, which sounds really unpleasant. Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -1 on that. We will get far more pushback from people whose application performance suddenly went to hell than we will ever get approval from people who actually need the feature. Considering that we've survived this long with leaky views, that should definitely remain the default behavior. Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest FAQ (was: dividing money by money)
[moving to -www list with bc to -hackers] Alvaro Herrera alvhe...@commandprompt.com wrote: BTW maybe the developer faq could use all the info gathered in this thread. I wound up putting a few sentences from this thread into the CommitFest Wiki page, and linking to that from the Submitting a Patch and Developer FAQ pages. I think it might be good to also have a link to the CommitFest Wiki page from the CommitFest Index page in the application. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Tom Lane t...@sss.pgh.pa.us wrote: Yeah. If we were to go with Greg's suggestion of inventing a separate is_relative_to_cwd test function, I'd expect that to insist on no .. while it was at it. So it's now two problems, and I think this is my final comment: 1. is_relative_to_cwd() I continue to think is a bad name for something concerned about .. (plus on Windows not having a drive letter other than the current one); the normal meaning of relative path is merely not absolute 2. if this proposed new function is to replace some uses of is_absolute_path() then I'm afraid I'd not picked up on that (as Bruce did) and have no opinion on whether it's a good idea or not, and am not qualified to be the one doing the code investigation (not enough knowledge of the code, it's beta time, and I'm frantically short of time just now as well, sorry) Giles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean giles.l...@pobox.com wrote: 1. is_relative_to_cwd() I continue to think is a bad name for something concerned about .. (plus on Windows not having a drive letter other than the current one); the normal meaning of relative path is merely not absolute Maybe something like is_under_cwd()? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. Ummm ... that makes semantics dependent on the permissions available at plan time, whereas what should matter is the permissions that exist at execution time. Maybe that's all right for this context but it doesn't seem tremendously desirable. Ugh. I hope there's a way around that problem because AFAICS the alternative is a world of hurt. If we're not allowed to take the security context into account during planning, then we're going to have to make worst-case assumptions, which sounds really unpleasant. Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -1 on that. We will get far more pushback from people whose application performance suddenly went to hell than we will ever get approval from people who actually need the feature. Considering that we've survived this long with leaky views, that should definitely remain the default behavior. Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? have you ruled out: 'create function'? :-) merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to pass around collation information
On lör, 2010-05-29 at 00:18 +0300, Heikki Linnakangas wrote: What does the spec have to say about the ctype used for upper() et al BTW? It doesn't make any provisions for locale dependencies for that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote: On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. Ummm ... that makes semantics dependent on the permissions available at plan time, whereas what should matter is the permissions that exist at execution time. Maybe that's all right for this context but it doesn't seem tremendously desirable. Ugh. I hope there's a way around that problem because AFAICS the alternative is a world of hurt. If we're not allowed to take the security context into account during planning, then we're going to have to make worst-case assumptions, which sounds really unpleasant. Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -1 on that. We will get far more pushback from people whose application performance suddenly went to hell than we will ever get approval from people who actually need the feature. Considering that we've survived this long with leaky views, that should definitely remain the default behavior. Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? have you ruled out: 'create function'? :-) You lost me... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
On Tue, Jun 1, 2010 at 4:57 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote: have you ruled out: 'create function'? :-) You lost me... Well, as noted by the OP, using views for security in postgres is simply wishful thinking. This is part of a family of issues (generally not evil nor fixable) under the category of 'there is no real control over when functions in a query fire'. My point was that in cases where users expect this behavior, why not encourage them to use functions instead of views? Is there any formal expectation that views can be used to hide data in this way? Does this really have to be fixed, and if so should it be in light of the fact that our rule system is basically understood to be broken? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: PGDLLEXPORT is __declspec (dllexport) only on MSVC, but is
井上です。 ご苦労様です。 このスレッド気になっていたのですが、ようやく少し 余裕ができたのでテストなどしてみました。 Takahiro Itagaki wrote: Log Message: --- PGDLLEXPORT is __declspec (dllexport) only on MSVC, but is __declspec (dllimport) on other compilers 私が知る限りdlimportがexportの引きがねになることは ないのでこの部分にはかなり違和感を感じていました。 実際__declspec(..)をすっぱり取り除いてmingwでbuild してみましたが少なくともinitdbでエラーになることは ありません。この場合の__declspec(dllimport)指定は 意味があるようには思えませんし運よく害がないだけだ という気がします。 because cygwin and mingw don't like dllexport. 一方__declspec(dllexport)指定は運悪く害があるのです が原因は単純ではなさそうです。エラーが発生している 場所はLoadLibrary()でありGetProcAddress()ではない ので関数がexportされないという原因ではなさそうです。 ネットを見て回ったところではdllwrap(及び？dlltool) を使っているのがまずいのかなという感触はありますが 明確な所はわかりません。又、それを避けるにはどうし たらよいのかがわかるほどmingwに詳しくはありません。 以上 参考まで Modified Files: -- pgsql/src/include/port: cygwin.h (r1.8 - r1.9) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/port/cygwin.h?r1=1.8r2=1.9) win32.h (r1.94 - r1.95) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/port/win32.h?r1=1.94r2=1.95) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Robert Haas wrote: On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean giles.l...@pobox.com wrote: 1. is_relative_to_cwd() I continue to think is a bad name for something ? concerned about .. (plus on Windows not having a drive letter other ? than the current one); the normal meaning of relative path is ? merely not absolute Maybe something like is_under_cwd()? Yeah, is_below_cwd? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Bruce Momjian br...@momjian.us writes: Robert Haas wrote: Maybe something like is_under_cwd()? Yeah, is_below_cwd? Hm. Neither of these obviously exclude the case of an absolute path that happens to lead to cwd. I'm not sure how important that is, but still ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Robert Haas wrote: Maybe something like is_under_cwd()? Yeah, is_below_cwd? Hm. Neither of these obviously exclude the case of an absolute path that happens to lead to cwd. I'm not sure how important that is, but still ... We currently do that with path_is_prefix_of_path(). Maybe that needs to be called as well. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Hm. Neither of these obviously exclude the case of an absolute path that happens to lead to cwd. I'm not sure how important that is, but still ... We currently do that with path_is_prefix_of_path(). Maybe that needs to be called as well. I think you misunderstood my point: in the places where we're insisting on a relative path, I don't think we *want* an absolute path to be accepted. What I was trying to say is that these proposed function names don't obviously mean a relative path that does not try to break out of cwd. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is_absolute_path incorrect on Windows
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Hm. Neither of these obviously exclude the case of an absolute path that happens to lead to cwd. I'm not sure how important that is, but still ... We currently do that with path_is_prefix_of_path(). Maybe that needs to be called as well. I think you misunderstood my point: in the places where we're insisting on a relative path, I don't think we *want* an absolute path to be accepted. What I was trying to say is that these proposed function names don't obviously mean a relative path that does not try to break out of cwd. Oh, OK. I know Magnus has a patch that he was working on and will send it out soon. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Performance Enhancement/Fix for Array Utility Functions
On Wed, Mar 31, 2010 at 9:47 AM, Mike Lewis mikelikes...@gmail.com wrote: Thanks. Added it. https://commitfest.postgresql.org/action/patch_view?id=292 I have reviewed this patch; this is my review: Regression tests pass with assertions enabled. Performance gains reported by author confirmed. The existence and naming of ARR_MAX_HEADER_SIZE is somewhat dubious, as it is: * Used in exactly one place (not necessarily a reason why it should not be reified into a stand-alone definition, though, but something to consider) * The array header refers to the NULL bitmap as well, but the interpretation used by the patch does not. I think this patch is safe, as all the array fields required are before the null bitmap, but I think the naming of this definition is very misleading. Generally I think the delimited untoasting of metadata from arrays separately from the payload is Not A Bad Idea. fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
(2010/06/01 22:16), Robert Haas wrote: 2010/6/1 Heikki Linnakangasheikki.linnakan...@enterprisedb.com: The general problem is that it seems like a nightmare to maintain this throughout the planner. Who knows what optimizations this affects, and do we need to hide things like row-counts in EXPLAIN output? If we try to be very strict, we can expect a stream of CVEs and security releases in the future while we find holes and plug them. On the other hand, using views to restrict access to underlying tables is a very useful feature, so I'd hate to just give up. We need to decide what level of isolation we try to accomplish. I'm entirely uninspired by the idea of trying to prevent all possible leakage of information via side-channels. Even if we tried to obfuscate the explain output, the user can still potentially get some information by timing how long queries take to execute. I think if we have a hook function that can prevent certain users from running EXPLAIN altogether (and I believe this may already be the case) that's about the appropriate level of worrying about that case. I think the only thing that we can realistically prevent is allowing users to make off with the actual tuples. It is a good point, I think. Even if we can guess or estimate something from circumstances, it does not allow unprivileged users to read information directly. In fact, we cannot find such a functionality to prevent side-channel leaks from the certification reports of commercial RDBMS with RLS (e.g; Oracle Label Security). However, the leaky VIEWs has a different characteristic. It unintentionally allows to fetch contents of invisible tuples and move into into other tables. It means here is a data flow channel (not side channel), but it breaks restriction of security views. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
(2010/06/01 22:09), Robert Haas wrote: 2010/6/1 KaiGai Koheikai...@ak.jp.nec.com: I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember where is originally put in the query, and prevent reordering over the nest level of subqueries. In above example, f_malicious() has nestlevel=0 because it is put on the top level. But f_policy() has nestlevel=1 because it is originally put on the second level subquery. Then, the order_qual_clauses() will check nestlevel of the scan filter prior to reorder them based on the cost estimation. Even if we have multiple nestlevels, solution will be same. A FuncExpr with larger nestlevel shall be invoked earlier than others. [...] My idea is similar to what I proposed at [1]. It adds a new field into RelOptInfo (or other structure?) to remember the original nestlevel of the scan, then it will be compared to nestlevel of the FuncExpr. If nestlevel of the FuncExpr is smaller than nestlevel of the RelOptInfo, it prevents to distribute the FuncExpr onto the RelOptInfo, even if the function depends on only the relation of RelOptInfo. Keep in mind that users who are NOT using a view as a security barrier don't expect it to kill performance. This approach, and particularly the second part, about preventing quals from being pushed through joins, has the potential to be a performance disaster. So I think it's absolutely critical that we don't do that except when it's necessary to prevent a security issue. Yes, I agree. It is necessary to distinguish security conscious views and others. In general, only creator of the view knows its intention correctly, so I think it is reasonable suggestion to provide a hint whether we should prevent a part of optimization, or not. On the technical side, I am pretty doubtful that the approach of adding a nestlevel to FuncExpr and RelOptInfo is the right way to go. I believe we have existing code (to handle left joins) that prevents quals from being pushed down too far by fudging the set of relations that are supposedly needed to evaluate the qual. I suspect a similar approach would work here. I think the steps here are: 1. Decide whether the view is a security barrier (perhaps, check whether the user has sufficient privs to execute the underlying query; or we could add an explicit setting). If not, stop. I'm a fun of an explicit setting. Queries are optimized prior to execution stage. 2. Decide whether each qual executes potentially untrusted code (algorithm?). A simple idea is to assume all the FuncExpr being potentially untrusted as a starting up of the fix. (Can we trust all the built-in functions? It needs to ensure they don't have any side-effects; in future versions also.) 3. Prevent any untrusted quals from being pushed down into view that is a security barrier. We should have a design for each of these before we start coding. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
(2010/06/02 2:28), Robert Haas wrote: On Tue, Jun 1, 2010 at 1:02 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haasrobertmh...@gmail.com writes: On Tue, Jun 1, 2010 at 10:57 AM, Tom Lanet...@sss.pgh.pa.us wrote: CREATE SECURITY VIEW, anyone? That may be the best approach, but I think it needs more than one line of exposition. The approach I proposed was to test whether the user has privileges to execute the underlying query directly without going through the view. If so, we needn't be concerned. If not, then we start thinking about which functions/operators we trust. Ummm ... that makes semantics dependent on the permissions available at plan time, whereas what should matter is the permissions that exist at execution time. Maybe that's all right for this context but it doesn't seem tremendously desirable. Ugh. I hope there's a way around that problem because AFAICS the alternative is a world of hurt. If we're not allowed to take the security context into account during planning, then we're going to have to make worst-case assumptions, which sounds really unpleasant. I was reminded that inline_set_returning_function() tries to extract a given RangeTblEntry with RTE_FUNCTION into a subquery when a few conditions are satisfied. The conditions include whether user has privileges to execute the function. It seems to me planner checks permissions, and going to have worst case assumptions, if access privilege violations. As long as we can resolve the problem that I described at [1] (order of evaluation of scan filters), it seems to me a reasonable fallback. (Although I mentioned that queries are optimized prior to execution stage...) Perhaps there is some value to having a knob that goes the opposite directions and essentially says I don't really care whether this view is leaky from a security perspective. But presumably we don't want to deliver that behavior by default and require the user to ask for a SECURITY VIEW to get something else - if anything, we'd want CREATE VIEW to create the normal (secure) version and add CREATE LEAKY VIEW to do the other thing. -1 on that. We will get far more pushback from people whose application performance suddenly went to hell than we will ever get approval from people who actually need the feature. Considering that we've survived this long with leaky views, that should definitely remain the default behavior. Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? How about a GUC option to provide the default, like default_with_oids? Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
2010/6/1 KaiGai Kohei kai...@ak.jp.nec.com: Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? How about a GUC option to provide the default, like default_with_oids? Bad idea. We already have enough problems with GUCs that can create security problems if they're unexpectedly set to the wrong value. We don't need any more. Anyhow, that's trivia. The real thing we need to decide here is to design the security mechanism. We can change the syntax to whatever we want very easily. Here's another thought. If we're leaning toward explicit syntax to designate security views (and I do mean IF, since only one person has signed on to that, even if it is Tom Lane!), then maybe we should think about ripping out the logic that causes regular views to be evaluated using the credentials of the view owner rather than the person selecting from it. A security view would still use that logic, plus whatever additional stuff we come up with to prevent leakage. Perhaps this would be viewed as a nasty backward compatibility break, but the upside is that we'd then be being absolutely clear that a non-security view isn't and can never be trusted to be a security barrier. Right now we're shipping something that purports to act as a barrier but really doesn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS
(2010/06/02 10:52), Robert Haas wrote: 2010/6/1 KaiGai Koheikai...@ak.jp.nec.com: Eh, if that's the consensus, it doesn't bother me that much, but it doesn't really answer the question, either: supposing we add an explicit concept of a security view, what should its semantics be? How about a GUC option to provide the default, like default_with_oids? Bad idea. We already have enough problems with GUCs that can create security problems if they're unexpectedly set to the wrong value. We don't need any more. Anyhow, that's trivia. The real thing we need to decide here is to design the security mechanism. We can change the syntax to whatever we want very easily. Indeed, syntax will be decided according to the logic. Here's another thought. If we're leaning toward explicit syntax to designate security views (and I do mean IF, since only one person has signed on to that, even if it is Tom Lane!), then maybe we should think about ripping out the logic that causes regular views to be evaluated using the credentials of the view owner rather than the person selecting from it. A security view would still use that logic, plus whatever additional stuff we come up with to prevent leakage. Perhaps this would be viewed as a nasty backward compatibility break, but the upside is that we'd then be being absolutely clear that a non-security view isn't and can never be trusted to be a security barrier. Right now we're shipping something that purports to act as a barrier but really doesn't. Sorry, should we make clear the purpose of explicit syntax for security views being issued now? In my understanding, if security views, the planner tries to checks privileges of the person selecting it to reference underlaying tables without any ereport. If violated, the planner prevents user given quals (perhaps FuncExpr only?) to come into inside of the join scan. Otherwise, if regular views, the planner works as is. Right? I don't think we need whatever additional user visible stuff to prevent leakage except for fully optimized query plan. (Of course, it can make performance regression.) It seems to me the issue is just an order to execute user defined functions and qualifier of security views to restrict visible tuples, so I don't know whether it breaks any backward compatibility. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao masao.fu...@gmail.com wrote: 4) Change it so that checkpoint_segments takes effect in standby mode, but not during recovery otherwise I revised the patch to achieve 4). This will enable checkpoint_segments to trigger a restartpoint like checkpoint_timeout already does, in standby mode (i.e., streaming replication or file-based log shipping). Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center checkpoint_segments_during_recovery_v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
