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
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
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?!?
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 t
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
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
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
"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
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
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 te
"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 TE
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
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 me
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
> c
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
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':
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 pierce
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 t
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 y
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 sh
20 matches
Mail list logo
