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
bottl
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 list
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
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
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 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
[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 wher
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 in
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 patc
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
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 r
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 <[EMA
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
> joi
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-E
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
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 existi
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 s
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 nev
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 su
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 y
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 paramateri
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 s
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
> >> fe
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 (pgsql-hackers@pos
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 -fno-stric
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
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 su
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 users
28 matches
Mail list logo
