On 12/02/2011 09:08 AM, Oleg Serov wrote:
Then i've analyzed log, and found this:
7 days ago appears this errors:
db= LOG: could not rename temporary statistics file
"pg_stat_tmp/pgstat.tmp" to "pg_stat_tmp/pgstat.stat":
db= WARNING: pgstat wait timeout
ERROR: missing chunk number 0 for toa
Indeed, there is a log message. My problem was that I missed to add
"listen_address='*'" to my postgresql.conf!
Hope this helps others in future.
Regards,
Edson Carlos Ericksson Richter
http://triangle-newhomes.com/view_articles.php?mid=46&detail=917&topic=89&topic=767&string=24
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi John,
Thanks for the replies.
The problem was the ident in the host. Problem solved.
Thanks a lot!
Best Regards,
On Fri, Dec 2, 2011 at 11:46 PM, John R Pierce wrote:
> On 12/02/11 3:41 PM, Andre Lopes wrote:
>>
>> My pg_hba.conf have this:
>> [code]
>> # TYPE DATABASE USER
On 12/02/11 3:41 PM, Andre Lopes wrote:
My pg_hba.conf have this:
[code]
# TYPE DATABASEUSERCIDR-ADDRESSMETHOD
# "local" is for Unix domain socket connections only
local all all ident
# IPv4 local connections:
hos
Hi Adrian,
Thanks for the reply.
My pg_hba.conf have this:
[code]
# TYPE DATABASEUSERCIDR-ADDRESSMETHOD
# "local" is for Unix domain socket connections only
local all all ident
# IPv4 local connections:
hostal
On 12/02/11 3:13 PM, Andre Lopes wrote:
[code]
Exception Value:
FATAL: Ident authentication failed for user "mypoatgreuser"
[/code]
There is more permissions that I must to give to the user
"mypoatgreuser"? What could be wrong here?
'ident' is the default authentication type for local
On Friday, December 02, 2011 3:13:41 pm Andre Lopes wrote:
> Hi,
>
> I've installed PostgreSQL 9.0 in CentOS6 I don't have configured
> anything in Postgre, I just created a user with this method:
>
>
> With the method above I have no problems in enter "psql" but when I
> try to connect with th
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Andre Lopes
Sent: Friday, December 02, 2011 6:14 PM
To: postgresql Forums
Subject: [GENERAL] Can't access to database from webapp in PostgreSQL 9.0, from
shell it is Ok.
Hi,
I've installed PostgreSQL 9.0 in CentOS6 I don't have configured
anything in Postgre, I just created a user with this method:
[article]
Here is how I do to create a Postgres user with the same username as
my regular login in Linux Ubuntu.
Go to your terminal with your regular user and do:
{
--- On Fri, 12/2/11, Tom Lane wrote:
> The only real fix for that will require cross-column
> statistics, which
> we don't have yet --- without such, there's no way for the
> planner to
> know that distributors have an atypical number of child
> customers.
The only caveat that I can think of
El 02/12/2011 04:50 p.m., Adrian Klaver escribió:
On Friday, December 02, 2011 2:33:05 pm Ing.Edmundo.Robles.Lopez wrote:
Hi!
I have the next messege:
LOG: checkpoints are occurring too frequently (-21093 seconds apart)
Postgres 8.3.11 is running on SCO Openserver 5.0.7
and this is my checkp
On Friday, December 02, 2011 2:33:05 pm Ing.Edmundo.Robles.Lopez wrote:
> Hi!
> I have the next messege:
> LOG: checkpoints are occurring too frequently (-21093 seconds apart)
>
> Postgres 8.3.11 is running on SCO Openserver 5.0.7
>
> and this is my checkpoint configuration:
> # - Checkpoints -
Hi!
I have the next messege:
LOG: checkpoints are occurring too frequently (-21093 seconds apart)
Postgres 8.3.11 is running on SCO Openserver 5.0.7
and this is my checkpoint configuration:
# - Checkpoints -
checkpoint_segments = 32# in logfile segments, min 1, 16MB each
checkpoint_ti
--- On Fri, 12/2/11, Tom Lane wrote:
> The only real fix for that will require cross-column
> statistics, which
> we don't have yet --- without such, there's no way for the
> planner to
> know that distributors have an atypical number of child
> customers.
>
I suspected as such.
> At the mo
--- On Fri, 12/2/11, David Johnston wrote:
>
>
> Can you wrap the query into an SQL or PL/pgSQL function so
> that, at least,
> then planner will not be able to see the embedded plan info
> in the outer
> queries? You use-case may allow
-Original Message-
From: Jeff Amiel [mailto:becauseimj...@yahoo.com]
Sent: Friday, December 02, 2011 5:07 PM
To: pgsql-general@postgresql.org; David Johnston
Subject: RE: [GENERAL] Oddball data distribution giving me planner headaches
--- On Fri, 12/2/11, David Johnston wrote:
> From:
Jeff Amiel writes:
> Oddball data distribution giving me headaches.
> [ 'distributor' customers have many more child customers than average ]
> Does this oddball data distribution doom me to poor planning forever?
The only real fix for that will require cross-column statistics, which
we don't hav
--- On Fri, 12/2/11, David Johnston wrote:
> From: David Johnston
> -
> My, possibly naïve, observation:
>
> So aside from the fact the estimates seem to be off the
> planner has still
> chosen the most effective plan? In that situati
"Gauthier, Dave" writes:
> SImple/quick (hopefully)
> thedb=# \dT+
>List of data types
> Schema | Name| Internal name | Size | Elements |
> Description
> +---+---+---+--+-
> public
-Original Message-
From: Jeff Amiel [mailto:becauseimj...@yahoo.com]
Sent: Friday, December 02, 2011 4:15 PM
To: pgsql-general@postgresql.org; David Johnston
Subject: RE: [GENERAL] Oddball data distribution giving me planner headaches
--- On Fri, 12/2/11, David Johnston wrote:
> What
--- On Fri, 12/2/11, David Johnston wrote:
> What happens if you disable, say, nested loops and/or index
> scans?
planner selects different join/indexing techniques (query is slower) but row
estimates (bad) remain identical.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
-Original Message-
From: Jeff Amiel [mailto:becauseimj...@yahoo.com]
Sent: Friday, December 02, 2011 3:52 PM
To: pgsql-general@postgresql.org; David Johnston
Subject: RE: [GENERAL] Oddball data distribution giving me planner headaches
--- On Fri, 12/2/11, David Johnston wrote:
> From:
2011/12/2 Merlin Moncure :
> On Fri, Dec 2, 2011 at 2:01 PM, Pavel Stehule wrote:
so bytea_agg - one param aggregate has sense
it's very easy to implement it
>>>
>>> yup:
>>>
>>> create aggregate bytea_agg (bytea)
>>> (
>>> sfunc=byteacat,
>>> stype=bytea
>>> );
>>
>> this is work
On Fri, Dec 2, 2011 at 2:01 PM, Pavel Stehule wrote:
>>> so bytea_agg - one param aggregate has sense
>>>
>>> it's very easy to implement it
>>
>> yup:
>>
>> create aggregate bytea_agg (bytea)
>> (
>> sfunc=byteacat,
>> stype=bytea
>> );
>
> this is workaround :)
>
> without a memory preallocati
--- On Fri, 12/2/11, David Johnston wrote:
> From: David Johnston
> What kind of plan does the following give?
>
> EXPLAIN ANALYZE
> SELECT *
> FROM customer_rel p
> JOIN customer c ON (p.parent_customer = c.customer_id)
> WHERE c.customer_type = 'DISTRIBUTOR'
Nearly identical output
"Nested
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Jeff Amiel
Sent: Friday, December 02, 2011 3:20 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Oddball data distribution giving me planner headaches
explain analyze
Oddball data distribution giving me headaches.
We have a distinct 'customer' table with customer_id, type and name/demographic
information.
Assume some 1 million rows in the customer table.
We then have a customer 'relationship' table which simply contains 2
columns…designating parent and chil
Hi:
SImple/quick (hopefully)
thedb=# \dT+
List of data types
Schema | Name| Internal name | Size | Elements | Description
+---+---+---+--+-
public | one_string_rec| one_string_rec
2011/12/2 Merlin Moncure :
> On Fri, Dec 2, 2011 at 11:15 AM, Pavel Stehule
> wrote:
>> 2011/12/2 Merlin Moncure :
>>> On Fri, Dec 2, 2011 at 10:42 AM, Marti Raudsepp wrote:
Sorry, but AFAICT this makes a mess of encodings and only works by
pure luck. The server thinks it's sending the
On Fri, Dec 2, 2011 at 11:15 AM, Pavel Stehule wrote:
> 2011/12/2 Merlin Moncure :
>> On Fri, Dec 2, 2011 at 10:42 AM, Marti Raudsepp wrote:
>>> Sorry, but AFAICT this makes a mess of encodings and only works by
>>> pure luck. The server thinks it's sending the client LATIN1 text, but
>>> it's ac
2011/12/2 Merlin Moncure :
> On Fri, Dec 2, 2011 at 10:42 AM, Marti Raudsepp wrote:
>> Sorry, but AFAICT this makes a mess of encodings and only works by
>> pure luck. The server thinks it's sending the client LATIN1 text, but
>> it's actually UTF8-encoded and the last decoding step is done by you
On Fri, Dec 2, 2011 at 10:42 AM, Marti Raudsepp wrote:
> Sorry, but AFAICT this makes a mess of encodings and only works by
> pure luck. The server thinks it's sending the client LATIN1 text, but
> it's actually UTF8-encoded and the last decoding step is done by your
> terminal.
yup -- your're ri
On Fri, Dec 2, 2011 at 16:16, Torsten Zuehlsdorff
wrote:
> But i clearly have a missunderstanding of other chars, like umlauts or utf-8
> chars. This, for example, should return a 'ö':
>
> # SELECT chr(x'C3B6'::int);
> chr
> -
> 쎶
> (1 row)
That gives you the Unicode codepoint C3B6, but %C3
Hi
I am getting some strange entries in the postgres logs when updating
data in a linked table using access.
If I create an UPDATE query I get the following entry which looks ok to
me
2011-12-01 10:18:38 GMT LOG: statement: UPDATE "ua"."pole_survey_tbl"
SET "completedby"=E'gavinm' WHERE "
On Thu, Dec 1, 2011 at 01:03, Tomas Vondra wrote:
> On 29.11.2011 23:38, Merlin Moncure wrote:
>> On Tue, Nov 29, 2011 at 7:49 AM, Heiko Wundram
>> wrote:
>>> Hello!
>>>
>>> Sorry for that subscribe post I've just sent, that was bad reading on my
>>> part (for the subscribe info on the homepage)
On Wed, Nov 30, 2011 at 6:03 PM, Tomas Vondra wrote:
> On 29.11.2011 23:38, Merlin Moncure wrote:
>> On Tue, Nov 29, 2011 at 7:49 AM, Heiko Wundram
>> wrote:
>>> Hello!
>>>
>>> Sorry for that subscribe post I've just sent, that was bad reading on my
>>> part (for the subscribe info on the homepa
Thank you! That did it!
I was able to execute the CREATE EXTENSION command. I hope it will work from
this point on, otherwise I know where to find help:)
Thanks again.
Florian
Am 30.11.2011 um 12:01 schrieb "Albe Laurenz" :
> Florian Schwendener wrote:
> [has problems building odbc_fdw]
>> Oh,
On Fri, Dec 2, 2011 at 8:16 AM, Torsten Zuehlsdorff
wrote:
> Damien Churchill schrieb:
>
>
>>> after several attempts I have finally succeeded in developing a
>>> urlencode()
>>> function to encode text correctly like defined in RFC 1738.
>>>
>>> Now i have a big problem: how to decode the text?
>
writes:
> Please consider this plpgsql function:
> = = = = = = = = = =
> CREATE Or Replace FUNCTION fx_order_by ( )
> RETURNS table( last_name text, first_name )
> AS $eofx$
> DECLARE
> --
> BEGIN
> Return Query
> select
> lname, fname
> from
> my_table
> order by
> lname ASC
Please consider this plpgsql function:
= = = = = = = = = =
CREATE Or Replace FUNCTION fx_order_by ( )
RETURNS table( last_name text, first_name )
AS $eofx$
DECLARE
--
BEGIN
Return Query
select
lname, fname
from
my_table
order by
lname ASC
;
END;
$eofx$ LANGUAGE plpgsql;
= =
Damien Churchill schrieb:
after several attempts I have finally succeeded in developing a urlencode()
function to encode text correctly like defined in RFC 1738.
Now i have a big problem: how to decode the text?
Example:
# SELECT urlencode('Hellö World!');
urlencode
-
>>On Tue, Nov 29, 2011 at 7:21 PM, Tyler Hains
wrote:
>> # explain analyze select * from cards where card_set_id=2850 order by
>> card_id limit 1;
>> QUERY
PLAN
>>
On 02/12/11 14:02, Gavin Mitchell wrote:
But if the data is changed within the table itself or a form based on
the table or query it starts a transaction and adds all available fields
into the where clause
2011-12-01 10:03:52 GMT LOG: statement: BEGIN;UPDATE
"ua"."pole_survey_tbl" SET "completed
Hi
I am getting some strange entries in the postgres logs when updating
data in a linked table using access.
If I create an UPDATE query I get the following entry which looks ok to
me
2011-12-01 10:18:38 GMT LOG: statement: UPDATE "ua"."pole_survey_tbl"
SET "completedby"=E'gavinm' WHERE "
On 2 December 2011 13:18, Torsten Zuehlsdorff wrote:
> Hello,
>
> after several attempts I have finally succeeded in developing a urlencode()
> function to encode text correctly like defined in RFC 1738.
>
> Now i have a big problem: how to decode the text?
>
> Example:
> # SELECT urlencode('Hellö
Hello,
after several attempts I have finally succeeded in developing a
urlencode() function to encode text correctly like defined in RFC 1738.
Now i have a big problem: how to decode the text?
Example:
# SELECT urlencode('Hellö World!');
urlencode
---
Hell%C3%B6%20
Hello!
i've don't try to do reindex. There was enough space.
And i have a full data-directory backup, when i've stop server, before
start.
2011/12/2 Venkat Balaji
>
> 2011/12/2 Oleg Serov
>
>> And, i'm an idiot.
>>
>> My DB version:
>> PostgreSQL 8.4.9 on x86_64-redhat-linux-gnu, compiled by
48 matches
Mail list logo
