Hi
We use plproxy for this kind of security enhancement. We create plpgsql
functions that do whats needed and then we create so called proxy database
that contains only plproxy interfaces for these functions. Users get access
only to proxy database. This way it is easier to rest assured that
2008/12/6 David Rowley [EMAIL PROTECTED]:
I've spent last night and tonight trying to break the patch and I've not
managed it.
I spent 2 and a half hours on the train last night reading over the patch
mainly for my own interest. I also went over the documentation and I have a
few
On Saturday 06 December 2008 22:38:29 James Mansion wrote:
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new
When i was performancing gmake, i got a error message. The attachment is the
detail, i have no ideas about it. Hope someone' help
Thanks
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
On Sunday 07 December 2008 12:06:44 Unicron wrote:
When i was performancing gmake, i got a error message. The attachment is
the detail, i have no ideas about it. Hope someone' help
You probably forgot make distclean before rebuilding.
--
Sent via pgsql-hackers mailing list
On Sat, 2008-12-06 at 13:30 -0500, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request
2008/12/6 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada Wrote:
2008/12/3 Hitoshi Harada [EMAIL PROTECTED]:
I am randomly trying some issues instead of agg common code (which I
now doubt if it's worth sharing the code), so tell me if you're
restarting your hack again. I'll send the whole
There is extra safety from using whitelists...
For one, it's trivial to write a query that consumes unlimited CPU
resources that accesses no built in tables or functions. There are
various other dangerous things that are difficult to lock down like
temp tables.
Assuming you can handle
Merlin Moncure wrote:
There is extra safety from using whitelists...
For one, it's trivial to write a query that consumes unlimited CPU
resources that accesses no built in tables or functions. There are
various other dangerous things that are difficult to lock down like
temp tables.
Assuming
Andrew Chernow wrote:
I think what is missing is a way to deny the execution of queries that
don't operate on an object (like a table, sequence, role, schema,
etc...), OR queries not covered by the priv system. Object-based
queries can be locked down using the existing priv system. Not
Peter Eisentraut wrote:
On Saturday 06 December 2008 22:38:29 James Mansion wrote:
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that
Hi,
the comment WRT WAL recovery and FS journals [1] is a bit misleading in
it's current form.
First, none of the general purpose filesystems I've seen so far do data
journalling per default, since it's a huge performance penalty, even for
non-RDBMS workloads. The feature you talk about is ext3
Andrew Dunstan wrote:
Andrew Chernow wrote:
I think what is missing is a way to deny the execution of queries that
don't operate on an object (like a table, sequence, role, schema,
etc...), OR queries not covered by the priv system. Object-based
queries can be locked down using the
2008/12/7 Hitoshi Harada [EMAIL PROTECTED]:
2008/12/7 Hitoshi Harada [EMAIL PROTECTED]:
2008/12/6 David Rowley [EMAIL PROTECTED]:
the time where the community can test further by committing this patch.
Agree. I'll send the latest patch and finish my work for now.
Here's the patch, including
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL version?
On Fri, Dec 5, 2008 at 4:08 PM, Merlin Moncure [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 9:53 AM, Dmitry Koterov [EMAIL PROTECTED] wrote:
Hello.
I can successfully ALTER a NON-EMPTY table
Gregory Stark [EMAIL PROTECTED] writes:
The following query causes an assertion failure on CVS head:
SELECT * FROM (SELECT 1 AS i) AS a WHERE NOT EXISTS (SELECT 1 WHERE 1 i);
Fixed, thanks for the report.
Looks like it's assuming there's at least one relation on each side of the
join.
Dmitry Koterov wrote:
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL version?
It is not currently on the TODO list.
---
On Fri, Dec 5, 2008 at 4:08 PM, Merlin Moncure [EMAIL
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of --disable-row-acl options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't
The proximate cause of this complaint:
http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
seems to be that the polymorphic-type code doesn't consider a domain
over an enum type to match an ANYENUM function argument.
ISTM this is probably wrong: we need such a domain to act like its
KaiGai Kohei wrote:
I hate to ask for something else from you, but I am trying to figure out
how we can proceed in reviewing and applying your additions. I am
wondering if you can produce a patch that has the SE-Linux part separate
so I can review the non-SE-Linux parts of the patch alone
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
Submission review:
Is the patch in standard form? Yes
Does it apply cleanly to current HEAD? Yes (with fuzz)
Does it
[EMAIL PROTECTED] writes:
As you can see in attached initdb.log, it seems fsm_search_avail is called
repeatedly and args are sort of looping...
That's expected, since the system is inserting a lot of tuples
successively. What it looks like to me is that the failing call is the
first one where
On Sun, Dec 7, 2008 at 7:57 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dmitry Koterov wrote:
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL version?
It is not currently on the TODO list.
Perhaps we could add it? It's been complained about more than
I understood your point. In the case of synchronous replication,
because slave fails over when master crashes, there're no need to
leave FPW from the beginning.
In this case, only prefetch will work. Fujii's code at the slave
looks very similar to pg_standby and pg_readahead will help in this
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
If you see a straightforward way, please submit a patch!
Will do that.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Tom Lane wrote:
[EMAIL PROTECTED] writes:
As you can see in attached initdb.log, it seems fsm_search_avail is called
repeatedly and args are sort of looping...
That's expected, since the system is inserting a lot of tuples
successively.
Right. I suspect it was in the infinite loop yet. Try
Andrew Dunstan wrote:
The most serious problem AFAIK is that we use setjmp/longjmp, which I
understand does not play at all nicely with C++ exceptions.
Considering the complexity of the code and how it at times stretches the
C standard to the point of cheating, I think anyone's three-item
Hitoshi Harada wrote:
It shows even though tuplestore trims its tuples and stays in memory
rather than dumps them on files, the performance up is only 2 sec in
50 sec. So I concluded the optimization for row_number()/rank() etc
doesn't pay for its more complexity in window function API. The
28 matches
Mail list logo
