2010/7/8 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/7/8 Robert Haas robertmh...@gmail.com:
A precompiler can give you all the same memory management benefits.
I use mmap(). And with mmap the precompiler are not necessary.
Dictionary is loaded only one
hello
2010/7/9 Takahiro Itagaki itagaki.takah...@gmail.com:
2010/7/8 Pavel Stehule pavel.steh...@gmail.com:
sorry, attached fixed patch
Make installcheck for contrib/stringfunc is broken.
Please run regression test with --enable-cassert build.
test stringfunc ... TRAP:
Consider the following small testcase:
BEGIN;
CREATE OR REPLACE FUNCTION upper(IN varchar, OUT varchar)
LANGUAGE SQL STRICT IMMUTABLE
AS
$$
SELECT pg_catalog.upper($1)::varchar;
$$;
CREATE TABLE foo(value varchar);
INSERT INTO foo SELECT 'helmle' FROM generate_series(1, 1000);
CREATE
2010/7/9 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/07/07 11:31), Robert Haas wrote:
On Tue, Jul 6, 2010 at 10:18 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just
On Thu, May 20, 2010 at 1:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As for committing it, I would definitely like to commit the actual
hook. If we want the hook without the contrib module that's OK with
me, although I generally feel it's useful to have examples of how
hooks can be used, which
On Fri, Jul 9, 2010 at 12:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
How long should I wait before I start breaking things?
Did you have any particular breakage in mind?
Well, you can see for yourself what I've submitted for the next CF.
You might
On Fri, 2010-07-09 at 14:06 +, Robert Haas wrote:
Log Message:
---
Add a hook in ExecCheckRTPerms().
This hook allows a loadable module to gain control when table permissions
are checked. It is expected to be used by an eventual SE-PostgreSQL
implementation, but there are
* Stephen Frost (sfr...@snowman.net) wrote:
Guess my first thought was that you'd have a database-level label that
would be used by SELinux to validate a connection. A second thought is
labels for roles. KaiGai, can you provide your thoughts on this
discussion/approach/problems? I realize
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
Today I went testing a patch on a recent PostgreSQL. I had to install
autoconf to configure the patched source. While seeing some other
packages getting installed on the
EnterpriseDB asked me to develop the attached patch to reduce the
on-disk size of numeric and to submit it for inclusion in PG 9.1.
After searching the archives, I found a possible design for this by
Tom Lane based on an earlier proposal by Simon Riggs.
On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
The loadable module doesn't gain control here it simplify kicks-in
after, and in addition to, normal checking. That just means you have the
option of failing for additional reasons.
True. We could change it so that the
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
Guess my first thought was that you'd have a database-level label that
would be used by SELinux to validate a connection. A second thought is
labels for roles. KaiGai, can you
* Simon Riggs (si...@2ndquadrant.com) wrote:
The loadable module doesn't gain control here it simplify kicks-in
after, and in addition to, normal checking. That just means you have the
option of failing for additional reasons.
Right, additional checks (such as the label) can be done.
We're
Simon Riggs si...@2ndquadrant.com writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
That would be a performance tweak that would render this change useless.
That seems both pointless and wrong.
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost sfr...@snowman.net wrote:
Something else which has come up but is related is the ability to
support a pam_tally-like function in PG. Basically, the ability to
lock users out if they've had too many
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost sfr...@snowman.net wrote:
Something else which has come up but is related is the ability to
support a pam_tally-like function
Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote:
Purely out of interest, since the old repo is still there, I had a
quick look at measuring the overhead, using 8.4's pgbench to run
two custom scripts: one consisting of a single 'SELECT 1', the
other having 100 'SELECT 1' - the latter being
Bernd Helmle maili...@oopsware.de writes:
-- assertion failure
EXPLAIN SELECT 1 FROM foo WHERE UPPER(value) = 'xyz';
I tried it back from current -HEAD to 8.3.11 and managed to reproduce it
everywhere. Non-cassert builds are working correctly, so i'm not sure
wether this is an
On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
That would be a performance tweak that would render this change useless.
Huh. Obviously, I would
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
That would be a performance tweak that would render this
On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
Rereading the thread, I'm a bit
On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs si...@2ndquadrant.com
wrote:
The loadable module doesn't gain control here it simplify kicks-in
after, and in addition to, normal checking. That just means you have
the
option of failing for
On Fri, 2010-07-09 at 11:09 -0400, Stephen Frost wrote:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are
updated.
That would be a performance tweak that would render this change
useless.
I don't see how you
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
With respect, there doesn't seem to be much use case anyway. I'm sorry
to be expressing that opinion now; been away for a while. I am somewhat
amazed that Tom isn't dancing on your head for proposing it though.
I believe it's because we've
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
That would be a
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Simon Riggs si...@2ndquadrant.com writes:
Agreed that permission checks should logically be applied at execution
time. I am proposing a performance optimisation, not a change in
behaviour.
Except that it *is* a change in behavior: the first check
On Fri, Jul 9, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing
On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
Agreed that permission checks should logically be applied at
execution
time. I am proposing a performance optimisation, not a change in
behaviour.
Except that it *is* a change in behavior: the first check will occur
too
soon.
Sooner
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
This is certainly true, but I also wonder what SE-PostgreSQL plans to
do about this. Taking this to its logical exteme, the system security
policy could change in mid-query - and while you'd like to think that
the system would stop
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
Except that it *is* a change in behavior: the first check will occur
too soon.
Sooner matters why?
Consider PREPARE followed only later by EXECUTE. Your proposal would
make the PREPARE fail
On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
I would not expect anything to work in an environment that is that
misconfigured. I would suggest running VirtualBox
On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
Except that it *is* a change in behavior: the first check will occur
too soon.
Sooner matters why?
Consider PREPARE followed only later by
On Fri, Jul 9, 2010 at 1:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and
2010/7/8 Pavel Baroš baro...@seznam.cz:
Description of patch:
1) can create MV, and is created uninitialized with data
CREATE MATERIALIZED VIEW mvname AS SELECT ...
This doesn't seem acceptable. It should populate it on creation.
2) can refresh MV
ALTER MATERIALIZED VIEW mvname REFRESH
On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
Here's the patch to add the 'xml_is_well_formed' function.
I suppose we should remove the function from contrib/xml2 at the same
time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Joshua D. Drake wrote:
On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
I would not expect anything to work in an environment that is that
misconfigured. I
On Fri, Jul 9, 2010 at 4:10 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Joshua D. Drake wrote:
On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
I would not expect
On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
Here's the patch to add the 'xml_is_well_formed' function.
I suppose we should remove the function from contrib/xml2 at the same
time.
Yep.
--
Robert Haas
2010/6/14 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch tries to rework DML permission checks.
It was mainly checked at the ExecCheckRTEPerms(), but same logic was
implemented in COPY TO/FROM statement and RI_Initial_Check().
This patch tries to consolidate these permission checks
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
Consider PREPARE followed only later by EXECUTE. Your proposal would
make the PREPARE fail outright, when it currently does not.
Just to avoid wasted investigation: are you saying that is important
Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
If anybody feels really uncomfortable with that, we could add a
compensating Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
atttype)) into get_attstatsslot(). Not sure if it's worth the cycles.
Cycles spent only in
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
If anybody feels really uncomfortable with that, we could add a
compensating Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
atttype)) into get_attstatsslot(). Not sure if
1;2401;0cOn Fri, Jul 09, 2010 at 06:49:27PM -0400, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
If anybody feels really uncomfortable with that, we could add a
compensating Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
atttype)) into
On Fri, Jul 9, 2010 at 10:25 PM, Boxuan Zhai bxzhai2...@gmail.com wrote:
Dear All,
This is ZHAI BOXUAN, a student of gSoC 2010. My project is to add merge
command in postgres.
This is the first submission of our codes, which has finished the parser,
analyzer and rewriter parts.
If you are
45 matches
Mail list logo
