hello
2010/7/9 Takahiro Itagaki :
> 2010/7/8 Pavel Stehule :
>> sorry, attached fixed patch
>
> Make installcheck for contrib/stringfunc is broken.
> Please run regression test with --enable-cassert build.
> test stringfunc ... TRAP:
> FailedAssertion("!(!lc_ctype_is_c())", File: "mbuti
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 I
2010/7/9 KaiGai Kohei :
> (2010/07/07 11:31), Robert Haas wrote:
>> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane wrote:
>>> Robert Haas writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just something that will CONFLICT WITH an
AccessExc
On Thu, May 20, 2010 at 1:33 PM, Tom Lane 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 is why I t
On Fri, Jul 9, 2010 at 12:54 AM, Tom Lane wrote:
> Robert Haas 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 want to hold off on the g
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 ar
* 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 realiz
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 scre
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.
http://archives.postgresql.org/pgsql-hackers
On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs 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 normal checking i
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost 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 provide 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
Simon Riggs 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. Permissions checks shoul
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost 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 failed log
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
>> > Something else which has come up but is related is the ability to
>> > support a "pam_tally"-like function in PG. Basically, the abil
Mark Kirkwood 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 probably the worst
> case
Bernd Helmle 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 over-aggressive assert() or
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
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
> Simon Riggs 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.
>
>
On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs wrote:
> On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
>> On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs wrote:
>> > On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
>> >> Rereading the thread, I'm a bit confused by why we're proposing to use
On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
> On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs
> 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
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 h
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 writes:
> On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
>> Simon Riggs 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 t
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 cours
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs 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 will occur too
On Fri, Jul 9, 2010 at 1:21 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
>>> Simon Riggs writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
>>
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.
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 emit
Simon Riggs 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 outright, when it curren
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 Virtual
On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
> Simon Riggs 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.
On Fri, Jul 9, 2010 at 1:18 PM, Simon Riggs 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 handle the update
2010/7/8 Pavel Baroš :
> 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
>
> 3) MV ca
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 subscripti
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 wou
On Fri, Jul 9, 2010 at 4:10 PM, Yeb Havinga 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 anythi
On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut 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
EnterpriseDB: http:
2010/6/14 KaiGai Kohei :
> 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 into a common
> f
Simon Riggs 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
> behaviour that
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 as
Alvaro Herrera 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 it's worth the cycl
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))" int
On Fri, Jul 9, 2010 at 10:25 PM, Boxuan Zhai 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 interested
44 matches
Mail list logo
