Wells Oliver wrote:
> Do you have any recommendations on a pg connection pooler?
If the software you're using includes a connection pool, that is
often the best choice; if not (or it doesn't work well) both pgpool
and pgbouncer have their followings.
In my view the most important things are
On May 31, 2011, at 11:31 AM, Kevin Grittner wrote:
You're probably overcommitting memory and running afoul of the oom
killer.
You've got an actual 12MB, but you can easily allocate up to
shared_buffers + (user_connections * work_mem), which is 18.5 GB. I
would start by reducing shared_buggers
Wells Oliver wrote:
> This has happened twice over the last couple of nights:
>
> 2011-05-30 02:08:27 PDT LOG: server process (PID 29979) was
> terminated by signal 9: Killed
> 2011-05-30 02:08:31 PDT FATAL: could not create shared memory
> segment: Cannot allocate memory
> To reduce the
This has happened twice over the last couple of nights:
2011-05-30 02:08:27 PDT LOG: server process (PID 29979) was terminated by
signal 9: Killed
2011-05-30 02:08:27 PDT LOG: terminating any other active server processes
2011-05-30 02:08:31 PDT LOG: all server processes terminated; reinitiali
On Tuesday 15 June 2010 23:31:26 Tom Lane wrote:
> Robert Voinea writes:
> >>> The problem is that after I update a table whenever I use a function
> >>> that makes use of dblink_build_sql the server crashes.
>
> FYI, I've committed patches to deal with this and some related issues.
>
Thank you
Robert Voinea writes:
>>> The problem is that after I update a table whenever I use a function that
>>> makes use of dblink_build_sql the server crashes.
FYI, I've committed patches to deal with this and some related issues.
regards, tom lane
--
Sent via pgsql-admin mai
Robert Voinea writes:
> I attached the server log (for the crash case) and a test case with logs.
> For that test case this is the error I get, no server crash.
> ERROR: invalid memory alloc request size 4294967293
> The scenario is this:
> Create a table, drop a column, any column then add a v
On Friday 11 June 2010 17:21:28 Tom Lane wrote:
> Robert Voinea writes:
> > I have a development database that is altered a lot and a set of
> > functions that make use of dblink_build_sql_*.
> > The problem is that after I update a table whenever I use a function that
> > makes use of dblink_buil
Robert Voinea writes:
> I have a development database that is altered a lot and a set of functions
> that make use of dblink_build_sql_*.
> The problem is that after I update a table whenever I use a function that
> makes use of dblink_build_sql the server crashes.
This is a bug, but you have n
Hi
I have the following issue:
I have a development database that is altered a lot and a set of functions
that make use of dblink_build_sql_*.
The problem is that after I update a table whenever I use a function that
makes use of dblink_build_sql the server crashes.
The ALTER TABLE sequences u
e t wrote:
All,
thanks for your kind reply.
We are indeed running rhel 2 es, as our application requires such.
I was able to correct this, including permission error, by
1)getting a right after the crash dump of the DB
2)dropping the DB
3)re-installing the RPM's via force option
4)re-importin
All,
thanks for your kind reply.
We are indeed running rhel 2 es, as our application requires such.
I was able to correct this, including permission error, by
1)getting a right after the crash dump of the DB
2)dropping the DB
3)re-installing the RPM's via force option
4)re-importing the DB
I a
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> 2: 7.4 series is up to 7.4.19. You may be missing 3 years of updates,
> unless you are using RedHat's version and they are back porting fixes
> to 7.4.7. I didn't think they did that, but Tom Lane would be a good
> person to ask about that.
Nope; Red
On Tue, Apr 29, 2008 at 11:18 AM, e t <[EMAIL PROTECTED]> wrote:
> Apr 29 13:15:34 cp postgres[4961]: [107-1] ERROR: could not open relation
> "users_pkey": Permission denied
Wait, permission denied? Sounds like the network monkeys in your NOC
are doing things they should not be doing, like chan
On Tue, Apr 29, 2008 at 11:18 AM, e t <[EMAIL PROTECTED]> wrote:
> Hello,
>
> we run
>
> 7.4.7
>
> on a Redhat RHEL server.
Two points.
1: The 7.4.x series is pretty old. You should consider upgrading to a
newer version when you have time. 8.3.1 is stable but a little new.
8.2.7 is very stable a
Hello,
we run
7.4.7
on a Redhat RHEL server.
Today that was a severe server crash and NOC seems to have repeatedly
attempted a reboot without properly unmounting the file systems.
I am getting errors such as the following
Apr 29 13:15:34 cp postgres[4961]: [106-1] ERROR: could not open rel
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Thanks. Just wondering, what's the difference in behavior from
> pgsql's perspective from sigquit and siqkill? Is sigkill more
> dangerous than sigquit?
Yes it is, because sigkill can't be trapped --- it causes instant
process death with no chance to
On Tue, Apr 22, 2008 at 10:06 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > From: Scott Marlowe [mailto:[EMAIL PROTECTED]
>
> >> Kill -9 is the "shoot it in the head" signal. It is not
> >> generated by postgresql in normal operation. It can be
> >> generated by "pg_ctl -m immediate stop" . At l
> From: Scott Marlowe [mailto:[EMAIL PROTECTED]
>> Kill -9 is the "shoot it in the head" signal. It is not
>> generated by postgresql in normal operation. It can be
>> generated by "pg_ctl -m immediate stop" . At least I think
>> that's what signal it sends.
Just for the archives: Postgres
> -Original Message-
> From: Scott Marlowe [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 22, 2008 10:13 AM
> To: Hajek, Nick
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Server Crash
>
> On Tue, Apr 22, 2008 at 8:14 AM, Hajek, Nick
>
On Tue, Apr 22, 2008 at 09:13:09AM -0600, Scott Marlowe wrote:
> On Tue, Apr 22, 2008 at 8:14 AM, Hajek, Nick <[EMAIL PROTECTED]> wrote:
> It's quite possible you're running your machine out of memory / swap
> somehow and linux is killing the biggest, fattest process it can find,
> which is pgsql.
On Tue, Apr 22, 2008 at 8:14 AM, Hajek, Nick <[EMAIL PROTECTED]> wrote:
>
>
> All,
> We experienced a crash of a Postgresql server which from the log appears to
> have began with this entry:
>
> Log: background writer process (PID 3457) was terminated by signal 9
Kill -9 is the "shoot it in the h
All,
We experienced a crash of a Postgresql server which from the log appears
to have began with this entry:
Log: background writer process (PID 3457) was terminated by signal 9
After the db was restarted, it operated apparently normally for about 15
minutes and then crashed again with the log
"Medora Schauer" <[EMAIL PROTECTED]> writes:
> PG: 7.3
I hope you meant "7.3.8", or at least something later than original 7.3 ;-)
> PANIC: link from /data/database/pg_xlog/000100D9 to
> /data/database/pg_xlog/000100E1 (initialization of log file 1,
> segment 225) failed: No su
OS: linux 2.4.18
h/w: moto 5100 SBC
PG: 7.3
We have a recurring problem with the pg server
crashing. It doesn’t happen often (once every couple of months or
so) but we require 24/7 up time. Attached is the pg.log from the
last time it crashed. The stuff towards the end seems to in
25 matches
Mail list logo
