Sam Stearns writes:
> I have a SELECT query that runs no problem standalone but when running
> within a perl script it intermittently core dumps. Random, no pattern
> to the timing of the core dumps. The perl script processes the rows
> from the query, if the rows satisfy a condition then the p
Howdy,
Environment:
Postgres 8.3.13
Solaris 10
I have a SELECT query that runs no problem standalone but when running
within a perl script it intermittently core dumps. Random, no pattern
to the timing of the core dumps. The perl script processes the rows
from the query, if the rows satisfy a
You will get the same behaviour from any database product where the query as
written requires type coercion - the coercion has to go in the direction of
the "wider" type. I have seen the exact same scenario with Oracle, and I
view it as a problem with the way the query is written, not with the
data
On Tue, Feb 8, 2011 at 3:08 PM, Greg Smith wrote:
> Scott Marlowe wrote:
>>
>> Are there any settings in postgresql.conf that would make it unsafe to
>> use -m immediate?
>>
>
> Two concerns:
>
> -Clients will be killed without any review, and data related to them lost
>
> -The server will have to
Scott Marlowe wrote:
Are there any settings in postgresql.conf that would make it unsafe to
use -m immediate?
Two concerns:
-Clients will be killed without any review, and data related to them lost
-The server will have to go through recovery to start back up again,
which could potentiall
Laszlo,
> Which is silly. I think that PostgreSQL converts the int side to a
> float, and then compares them.
>
> It would be better to do this, for each item in the loop:
>
> * evaluate the right side (which is float)
> * tell if it is an integer or not
> * if not an integer, then d
Scott Marlowe wrote:
> Greg Smith wrote:
>> Kevin and I both suggested a "fast plus timeout then immediate"
>> behavior is what many users seem to want.
> Are there any settings in postgresql.conf that would make it
> unsafe to use -m immediate?
I don't think so. There could definitely be
On Tue, Feb 8, 2011 at 1:09 PM, Greg Smith wrote:
> Marti Raudsepp wrote:
>>
>> I couldn't find any past discussions about changing the default to "fast".
>> Are there any reasons why that cannot be done in a future release?
>>
> Kevin and I both suggested a "fast plus timeout then immediate" beha
Marti Raudsepp wrote:
> Greg Smith wrote:
>> Kevin and I both suggested a "fast plus timeout then immediate"
>> behavior is what many users seem to want.
> Seems that a better solution would be implementing a new -m option
> that does this transparently?
Maybe. Another option might be to use
On Tue, Feb 8, 2011 at 22:09, Greg Smith wrote:
> Kevin and I both suggested a "fast plus timeout then immediate" behavior is
> what many users seem to want. My comments were at
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01145.php ; for an
> example of how fast shutdown can fail se
Marti Raudsepp wrote:
I couldn't find any past discussions about changing the default to "fast".
Are there any reasons why that cannot be done in a future release?
Well, it won't actually help as much as you might think. It's possible
for clients to be in a state where fast shutdown doesn'
I also tried to do table partitioning using the same immutable function,
it works well except for constraint exclusion.
CREATE TABLE mike.directory_part_0 () INHERITS (mike.directory) WITH
(fillfactor = 90);
CREATE RULE directory_part_0_insert AS ON INSERT TO mike.directory WHERE
(__mod_cons_has
Marti Raudsepp wrote:
> I couldn't find any past discussions about changing the default to
> "fast".
It's not entirely unrelated to the "Linux LSB init script" in August
and September of 1009:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php
http://archives.postgresql.org/
>> I couldn't find any past discussions about changing the default to "fast".
>> Are there any reasons why that cannot be done in a future release?
>
> Or at least throw a hint the user's way that -m fast might be needed.
I think there are several issues here:
1. Does pg_ctl give a clear indicati
On Tue, Feb 8, 2011 at 9:50 AM, Marti Raudsepp wrote:
> On Tue, Feb 8, 2011 at 18:36, Kevin Grittner
> wrote:
>> Yeah, current behavior with that shutdown option is the opposite of
>> smart for any production environment I've seen. (I can see where it
>> would be handy in development, though.)
On Tue, 2011-02-08 at 06:15 +0100, Jesper Krogh wrote:
> On 2011-02-08 01:14, Sylvain Rabot wrote:
> > CREATE INDEX directory_id_user_mod_cons_hash_0_btree_idx ON mike.directory
> > USING btree (id_user) WHERE __mod_cons_hash(id_user, 4) = 0;
> > CREATE INDEX directory_id_user_mod_cons_hash_1_btre
On Tue, Feb 8, 2011 at 18:36, Kevin Grittner
wrote:
> Yeah, current behavior with that shutdown option is the opposite of
> smart for any production environment I've seen. (I can see where it
> would be handy in development, though.) What's best in production
> is the equivalent of the fast opti
Maciek Sakrejda wrote:
>>> Well it said "Failed to shutdown ..." and then
>>> returned control. and then proceeded to run for about an hour.
>>> I'm not sure how graceful that is.
>>
>> Ah, but that was just the control script that sends the database
>> the command to shut down. T
>> Well it said "Failed to shutdown ..." and then
>> returned control. and then proceeded to run for about an hour. I'm
>> not sure how graceful that is.
>
> Ah, but that was just the control script that sends the database the command
> to shut down. The 'graceful' part, is that th
This query:
select p.id,p.producer_id,visa.variation_item_id, vi.qtyavail
from variation_item_sellingsite_asin visa
inner join product p on p.id = visa.product_id
inner join variation_item vi on vi.id =
visa.var
On 02/07/2011 09:17 PM, felix wrote:
Well it said "Failed to shutdown ..." and then
returned control. and then proceeded to run for about an hour. I'm
not sure how graceful that is.
Ah, but that was just the control script that sends the database the
command to shut down. The
Hello
it isn't surprise. PL/pgSQL hasn't own arithmetic unit. All
expressions are transformed to simple SELECTs.
Probably you can find a tasks, where Perl should be 10, 100, 1000x
faster than PL/pgSQL - array sort, array creation, ..
On second hand, PL/pgSQL is very fast with embeded SQL.
So if
Hi.
I do small test of plsql and perl.Result is that perl may be
2xfaster in simple loops.
CREATE OR REPLACE FUNCTION _.test1() RETURNS void AS
$BODY$
declare i integer; j bigint := 0;
begin
for i in 1..100 loop j:=j+i; end loop;
end;
$BODY$ LANGUAGE plpgsql VOLATILE COST 100;
"Result
Hi Josh,
it's "known" issue, see this thread:
http://archives.postgresql.org/pgsql-hackers/2010-02/thrd6.php#01290
HTH,
Kuba
Dne 8.2.2011 2:39, Josh Berkus napsal(a):
Ooops.
It looks like you are right, see ./src/backend/postmaster/pgstat.c
3c2313f4 (Tom Lane 2008-11-03 01:17:08
24 matches
Mail list logo
