date:20111110

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Torsten Zuehlsdorff


Heikki Linnakangas schrieb:

On 10.11.2011 07:09, Robert Young wrote:

2.If the underling lack of hostname or DNS facility, Anyway, PG should
be founctional without it.


It is. It's just the stats collector that won't work, and autovacuum 
which depends on a working stats collector. Otherwise the system is 
functional.


But it will get broken! Without the autovacuum (and a manual vacuum) a 
PG installation could run into loss of (very) old data, because of the 
transaction ID wraparound.


Lossing data is very bad, the solution provided by Robert is really 
simple. I support Roberts approach.


Greetings from Germany,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8 
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse 
auswerten kann.


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread John R Pierce


On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:
Lossing data is very bad, the solution provided by Robert is really 
simple. I support Roberts approach. 


you support changing localhost to be something other than 127.0.0.1 to 
hack around a poorly designed application?!?   seriously?



--
john r pierceN 37, W 122
santa cruz ca mid-left coast


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Torsten Zuehlsdorff


John R Pierce schrieb:

On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:
Lossing data is very bad, the solution provided by Robert is really 
simple. I support Roberts approach. 


you support changing localhost to be something other than 127.0.0.1 to 
hack around a poorly designed application?!?   seriously?


No, i support that PG should be able to not lossing data because of an 
easily catchable missconfiguration of the underlying system.


Greetings,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8 
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse 
auswerten kann.


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Heikki Linnakangas


On 10.11.2011 11:26, Torsten Zuehlsdorff wrote:

John R Pierce schrieb:

On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:

Lossing data is very bad, the solution provided by Robert is really
simple. I support Roberts approach.


you support changing localhost to be something other than 127.0.0.1 to
hack around a poorly designed application?!? seriously?


No, i support that PG should be able to not lossing data because of an
easily catchable missconfiguration of the underlying system.


You won't lose data. There are safeguards in place to print warnings in 
the log when you approach transaction wrap-around, and after a certain 
point the system will stop accepting new transactions, to prevent data loss.


If autovacuum is not working and you're not doing manual vacuums, you 
will likely have an extremely bloted database anyway, before you reach 
wrap-around.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

2011-11-10 Thread Maksym Boguk


The following bug has been logged online:

Bug reference:  6288
Logged by:  Maksym Boguk
Email address:  maxim.bo...@gmail.com
PostgreSQL version: 9.1
Operating system:   Linux Ubuntu
Description:Is ALTER ROLE set client_encoding broken in 9.1?
Details: 

I found common way deal with legacy applications encoding issues through 
ALTER ROLE ... set client_encoding '...';

Doesn't work at 9.1 database:

test:

postgres@db13:/home/mboguk$ psql
psql (9.1.1)
Type "help" for help.

postgres=# CREATE DATABASE test WITH TEMPLATE = template0  ENCODING='KOI8R'
LC_COLLATE = 'ru_RU.KOI8-R' LC_CTYPE = 'ru_RU.KOI8-R';
CREATE DATABASE
postgres=# create role test with login;
CREATE ROLE
postgres=# alter role test set client_encoding to 'KOI8R';
ALTER ROLE
postgres=# \q

postgres@db13:/home/mboguk$ psql -U test
psql (9.1.1)
Type "help" for help.

test=> show client_encoding ;
 client_encoding
-
 UTF8
(1 row)

The same way work without any issues with 8.3 and 8.4.

PS: it's possible i'm missing something obvious.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Robert Young

The answer is simple.
You said, just the stats collector have some trouble.
Then I say, I just want to fix the stats collector.
You said, other things are OK.
Then I say, I never want to fix other things.

I just plead with you to fix the very thing that you admit not
functional properly.
The whole database is almost functional, we won't fix the whole.
Component of it get in trouble, we fix the component.
The whole is almost functional can be a reason that we should not fix
the nonfunctional component.

On Thu, Nov 10, 2011 at 06:36, Heikki Linnakangas
 wrote:
> On 10.11.2011 07:09, Robert Young wrote:
>>
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be functional without it.
>
> It is. It's just the stats collector that won't work, and autovacuum which
> depends on a working stats collector. Otherwise the system is functional.
>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Robert Young

The answer is simple.
You said, just the stats collector have some trouble.
Then I say, I just want to fix the stats collector.
You said, other things are OK.
Then I say, I never want to fix other things.

I just plead with you to fix the very thing that you admit not
functional properly.
The whole database is almost functional, we won't fix the whole.
Component of it get in trouble, we fix the component.
The whole is almost functional can NOT be a reason that we should not
fix the nonfunctional component.

On Thu, Nov 10, 2011 at 06:36, Heikki Linnakangas
 wrote:
> On 10.11.2011 07:09, Robert Young wrote:
>>
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be founctional without it.
>
> It is. It's just the stats collector that won't work, and autovacuum which
> depends on a working stats collector. Otherwise the system is functional.
>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

2011-11-10 Thread Tom Lane

"Maksym Boguk"  writes:
> Description:Is ALTER ROLE set client_encoding broken in 9.1?

No, but I think psql prefers to set its encoding according to its locale
enviroment these days.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] HElp

2011-11-10 Thread MOHSEN MOMENI

I use this command for create TEMPORARY TABLE
now affter use this temporary i want DROP this Table but NOT WORk IF EXIST
TEMPORARY TABLE in PGsql 8.1
for this please help me

SELECT connection_log_details.connection_log_id,
textcat_all(connection_log_details.value || '|')
  INTO TEMPORARY log
  FROM connection_log_details
  GROUP BY connection_log_details.connection_log_id limit 2010;
  select * from log;

DROP TABLE  log;


and

i useaggre gate in pgsql 8 and for test use this not have
CREATE if exist  AGGREGATE

please help me

[BUGS] BUG #6289: help us

2011-11-10 Thread mohsen


The following bug has been logged online:

Bug reference:  6289
Logged by:  mohsen
Email address:  momenimoh...@gmail.com
PostgreSQL version: 8.1
Operating system:   centos
Description:help us
Details: 

I use this command for create TEMPORARY TABLE 

now affter use this temporary i want DROP this Table but NOT WORk IF EXIST
TEMPORARY TABLE in PGsql 8.1 

for this please help me 


SELECT connection_log_details.connection_log_id,
textcat_all(connection_log_details.value || '|')
  INTO TEMPORARY log 
  FROM connection_log_details
  GROUP BY connection_log_details.connection_log_id limit 2010;
  select * from log;

 

DROP TABLE  log;

 

 

and

 

i useaggre gate in pgsql 8 and for test use this not have  

CREATE if exist  AGGREGATE 

 

please help me

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6289: help us

2011-11-10 Thread Kevin Grittner

"mohsen"  wrote:

> PostgreSQL version: 8.1

That's no longer a supported version.  8.2 goes out of support next
month.  Please upgrade to something more recent.

> I use this command for create TEMPORARY TABLE 
> 
> now affter use this temporary i want DROP this Table but NOT WORk
> IF EXIST TEMPORARY TABLE in PGsql 8.1 

> SELECT connection_log_details.connection_log_id,
> textcat_all(connection_log_details.value || '|')
>INTO TEMPORARY log 
>FROM connection_log_details
>GROUP BY connection_log_details.connection_log_id limit 2010;
>select * from log;
> 
> DROP TABLE  log;

> i useaggre gate in pgsql 8 and for test use this not have  
> 
> CREATE if exist  AGGREGATE 

It's not at all clear what you want help with, but nothing above
sounds remotely like a bug.  Please read this page and post to a
more appropriate list (like pgsql-general) with more information. 
If you have multiple issues, it would be best to start a separate
thread for each one, with a subject line appropriate to the topic. 
"help us" doesn't give any clue what the topic is.

http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

-Kevin

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

2011-11-10 Thread Maxim Boguk

Thank you very much for information. I lost some brain cells during
fighting with that problem yesterday.

However personally I'm think this behavior is rather non-intuitive:

postgres@db13:~$ psql -U slony -d test -c 'show client_encoding'
 client_encoding
-
 UTF8
(1 row)

postgres@db13:~$ psql -U slony -d test -c 'show client_encoding' | head -10
 client_encoding
-
 KOI8R
(1 row)

On Fri, Nov 11, 2011 at 1:55 AM, Tom Lane  wrote:
> "Maksym Boguk"  writes:
>> Description:        Is ALTER ROLE set client_encoding broken in 9.1?
>
> No, but I think psql prefers to set its encoding according to its locale
> enviroment these days.
>
>                        regards, tom lane
>

-- 
Maxim Boguk
Senior Postgresql DBA.

Skype: maxim.boguk
Jabber: maxim.bo...@gmail.com

LinkedIn profile: http://nz.linkedin.com/in/maximboguk
If they can send one man to the moon... why can't they send them all?

МойКруг: http://mboguk.moikrug.ru/
Сила солому ломит, но не все в нашей жизни - солома, да и сила далеко не все.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] HElp

2011-11-10 Thread Craig Ringer

Messages with the subject "Help" usually don't get much response. Also, 
this is not a bug report. If you have questions or need help, try the 
pgsql-general or pgsql-novice mailing lists (as the bug report form 
advised you to do) or ask on the EnterpriseDB forums.


Please do not reply to this message. If you want more help, use one of 
the places mentioned above.


When you ask for more help in an appropriate place, rather than just 
saying "it doesn't work" please copy and paste the ERROR MESSAGES you 
get when you run it. See:


http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

PostgreSQL 8.1 is obsolete and unmaintained. You should update.

"CREATE IF NOT EXISTS AGGREGATE" is invalid and does not exist, so you 
cannot use it. See the help:


-
db=> \h create aggregate
Command: CREATE AGGREGATE
Description: define a new aggregate function
Syntax:
CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
SFUNC = sfunc,
STYPE = state_data_type
[ , FINALFUNC = ffunc ]
[ , INITCOND = initial_condition ]
[ , SORTOP = sort_operator ]
)

or the old syntax

CREATE AGGREGATE name (
BASETYPE = base_type,
SFUNC = sfunc,
STYPE = state_data_type
[ , FINALFUNC = ffunc ]
[ , INITCOND = initial_condition ]
[ , SORTOP = sort_operator ]
)
-

--
Craig Ringer

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

2011-11-10 Thread Tom Lane

Maxim Boguk  writes:
> However personally I'm think this behavior is rather non-intuitive:

> postgres@db13:~$ psql -U slony -d test -c 'show client_encoding'
>  client_encoding
> -
>  UTF8
> (1 row)

> postgres@db13:~$ psql -U slony -d test -c 'show client_encoding' | head -10
>  client_encoding
> -
>  KOI8R
> (1 row)

I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Bruce Momjian

Robert Young wrote:
> The answer is simple.
> You said, just the stats collector have some trouble.
> Then I say, I just want to fix the stats collector.
> You said, other things are OK.
> Then I say, I never want to fix other things.
> 
> I just plead with you to fix the very thing that you admit not
> functional properly.
> The whole database is almost functional, we won't fix the whole.
> Component of it get in trouble, we fix the component.
> The whole is almost functional can NOT be a reason that we should not
> fix the nonfunctional component.

You are free to distribute your own version of Postgres that does
whatever you think is best.  Our community has given ample thought to
your ideas and has rejected them.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #6290: converting interval from weeks to days

2011-11-10 Thread Alexey Nalbat


The following bug has been logged online:

Bug reference:  6290
Logged by:  Alexey Nalbat
Email address:  alexey_nal...@hotbox.ru
PostgreSQL version: 9.1.1
Operating system:   Ubuntu
Description:converting interval from weeks to days
Details: 

=> select '10 weeks'::interval;
 interval 
--
 -1589934592 days
(1 row)

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6290: converting interval from weeks to days

2011-11-10 Thread John R Pierce


On 11/10/11 1:15 PM, Alexey Nalbat wrote:

=>  select '10 weeks'::interval;
  interval
--
  -1589934592 days


a billion weeks is like 19 million years.  somehow, I don't think that 
postgresql's date math has quite that range.



--
john r pierceN 37, W 122
santa cruz ca mid-left coast


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

2011-11-10 Thread Robert Young

Anyway...
Thanks to all of you for answering my puzzles, even though none of you
gave feasible answer ...

On Fri, Nov 11, 2011 at 00:42, Bruce Momjian  wrote:
> Robert Young wrote:
>> The answer is simple.
>> You said, just the stats collector have some trouble.
>> Then I say, I just want to fix the stats collector.
>> You said, other things are OK.
>> Then I say, I never want to fix other things.
>>
>> I just plead with you to fix the very thing that you admit not
>> functional properly.
>> The whole database is almost functional, we won't fix the whole.
>> Component of it get in trouble, we fix the component.
>> The whole is almost functional can NOT be a reason that we should not
>> fix the nonfunctional component.
>
> You are free to distribute your own version of Postgres that does
> whatever you think is best.  Our community has given ample thought to
> your ideas and has rejected them.
>
> --
>  Bruce Momjian          http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + It's impossible for everything to be true. +
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6289: help us

2011-11-10 Thread Craig Ringer


Read this please:

http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

On 11/10/2011 09:59 PM, mohsen wrote:

PostgreSQL version: 8.1

8.1.**WHAT** ?

There are lots of bug fix releases in the 8.1 series and nobody here has 
psychic powers that let them tell which one you're using. When you 
report a bug, that's kinda important.

Operating system:   centos

"CentOS" isn't very informative. CentOS ***WHAT***? Try, eg:

   CentOS 5 running 2.6.28-2-i686 as a Xen domU guest


Description:help us


If you want help, that's about the least useful subject line to use. 
Most people will ignore uninformative subject lines like "Help" or "help 
me, urgent".


Didn't you just post a similar "bug report" earlier, anyway?

Try asking in the appropriate place:

http://archives.postgresql.org/pgsql-novice/
http://archives.postgresql.org/pgsql-general/ 


http://forums.enterprisedb.com/forums/list.page

... after reading this:

http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

--
Craig Ringer

Re: [BUGS] BUG #6290: converting interval from weeks to days

2011-11-10 Thread Craig Ringer


On 11/11/2011 09:35 AM, John R Pierce wrote:

On 11/10/11 1:15 PM, Alexey Nalbat wrote:

=> select '10 weeks'::interval;
interval
--
-1589934592 days


a billion weeks is like 19 million years. somehow, I don't think that
postgresql's date math has quite that range.


It should probably detect overflow and fail with an error like Pg does 
with other overflow conditions, though. I think that was probably the point.


--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

[BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

[BUGS] HElp

[BUGS] BUG #6289: help us

Re: [BUGS] BUG #6289: help us

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

Re: [BUGS] HElp

Re: [BUGS] BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

[BUGS] BUG #6290: converting interval from weeks to days

Re: [BUGS] BUG #6290: converting interval from weeks to days

Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

Re: [BUGS] BUG #6289: help us

Re: [BUGS] BUG #6290: converting interval from weeks to days

20 matches

Site Navigation

Mail list logo

Footer information