--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Hello,
how fatal is it for the server/data if a server runs out of memory?
Happened on a Windows server some time ago. A transaction got too large. In the
log it began with:
TopMemoryContext: 37171728 total in 4046 blocks; 67640 free (4060 chunks);
37104088 used
TopTransactionC
2010/5/3 Jan-Peter Seifert :
> Hello,
>
> how fatal is it for the server/data if a server runs out of memory?
>
> Happened on a Windows server some time ago. A transaction got too large. In
> the log it began with:
>
>
> TopMemoryContext: 37171728 total in 4046 blocks; 67640 free (406
Couple of things to try:
- The default process is not postmaster any more, rather is it postgres:
http://www.postgresql.org/docs/8.4/interactive/server-start.html
- Try manually starting up the postgres with the debug cranked all the way up,
see what that gives you in the server logs
- Perhaps
Maybe SElinux is in the way?
Dai, Tino wrote:
Couple of things to try:
- The default process is not postmaster any more, rather is it postgres:
http://www.postgresql.org/docs/8.4/interactive/server-start.html
- Try manually starting up the postgres with the debug cranked all the way up,
see
"Daniel J. Summers" wrote:
> 2010-05-03 03:36:06 UTC HINT: Is another postmaster already
> running on port 5432? If not, wait a few seconds and retry.
Just to be thorough, you got the same errors in the log when you
tried the start later?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql
Benjamin Krajmalnik wrote:
> OK.
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum launch
> process was running.
Did you check the server log for FATAL or ERROR lines? Maybe it's dying
trying to vacuum some table and
"Benjamin Krajmalnik" wrote:
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum
> launch process was running.
Like last time, all ten autovacuum workers were running? What does
CPU and disk activity look like in t
Yeb Havinga writes:
>> 2010-05-03 03:36:06 UTC LOG: could not bind IPv4 socket: Cannot assign
>> requested address
Does it work if you change listen_addresses to '*' or '127.0.0.1' ?
>> ..and localhost is resolving...
>> r...@coolnewserver:~# nslookup localhost
nslookup isn't a terribly reliab
On 05/03/2010 11:55 AM, Dai, Tino wrote:
Couple of things to try:
- The default process is not postmaster any more, rather is it postgres:
http://www.postgresql.org/docs/8.4/interactive/server-start.html
Any idea where this would be located? It's not in any of the usual
places. I found
"Benjamin Krajmalnik" writes:
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum launch
> process was running.
Hmm ... could you strace the launcher for a couple of minutes to see
whether it's doing anything?
Also, I
On 05/03/2010 01:52 PM, Tom Lane wrote:
Yeb Havinga writes:
2010-05-03 03:36:06 UTC LOG: could not bind IPv4 socket: Cannot assign
requested address
Does it work if you change listen_addresses to '*' or '127.0.0.1' ?
Bingo - changing it to "*" got it started. :)
..and
"Daniel J. Summers" writes:
> On 05/03/2010 01:52 PM, Tom Lane wrote:
>> Does it work if you change listen_addresses to '*' or '127.0.0.1' ?
> Bingo - changing it to "*" got it started. :)
OK, what about 127.0.0.1? Given that "dig localhost" returns that,
it *should* behave the same, but obvio
Tom Lane wrote:
> Also, I've forgotten exactly which PG version you're running?
The original post said:
PostgreSQL 8.4.3 amd64 on FreeBSD 7.2.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Dear Recipient ;
I have a batch of SQL script .As I run that in
agAdmin||| there display an error .
But I am unable to find the line which is producing the error .
please inform me is there any software that can be use to debug the query
using in postgres .
I shall be than
HI,
I have a vacuum process that has been running on a table for the past 20 days.
The server is postgres 8.3 on ubuntu linux.
Can I safely kill the vacuum with:
select pg_cancel_backend(26433)
Some stats
The table sees ~5million and not more than ~10million updates month
$ ps aux | gre
I was connecting to Postgres 8.3 through JDBC. During my unit tests, something
when wrong and now leaving with the following locks in the db:
arc_dev=# select locktype, mode, relname, virtualtransaction, pid from pg_locks
l join pg_class c on l.relation = c.oid;
Hi,
I have a number of PostgreSQL servers which I often access through ssh
tunnel with Pgadmin3. I would like to double check which one I have landed
on (if the tunnel is really configured the way I want). Is there a way to
query the hostname from the catalogs?
Thanks
Peter
"M.Nasir Aftab" wrote:
> I have a batch of SQL script .As I run that in
> agAdmin||| there display an error .
> But I am unable to find the line which is producing the error .
It's hard to know what to suggest without knowing what the script is
or what the error is. This page may give you som
Tom,
1. I had to restart the postgres server, otherwise I would have been in
deep problems.
2. I just tried installing strace from the ports system - unfortunately
it appears that FreeBSD only has it for i38s, not amd64. Any
alternatives so that if this happens again I can take care of this?
>
I did not find any errors pertaining to the autovacuum task.
In both cases we had a data-centric issue which was causing excessive
errors on the database (we have a timestamp field and an external
utility which we use to collect product keys was sending the date as
"dd/mm/ hh:mm:ss" for some en
Benjamin Krajmalnik wrote:
> I did not find any errors pertaining to the autovacuum task.
Hmm. I think it would be good to find out what is the launcher doing,
if anything. If you strace it, do you see it sending signals to
postmaster?
--
Alvaro Herrerahttp://ww
On 05/03/2010 02:20 PM, Tom Lane wrote:
"Daniel J. Summers" writes:
On 05/03/2010 01:52 PM, Tom Lane wrote:
Does it work if you change listen_addresses to '*' or '127.0.0.1' ?
Bingo - changing it to "*" got it started. :)
OK, what about 127.0.0.1? Given that "di
23 matches
Mail list logo
