Thanks. Comments below. (PS: I am still unable to connect to
postgresql even in SSH! I see this message:
psql: could not connect to server: Connection timed out
Is the server running on host "localhost" and accepting
TCP/IP connections on port 5432?
Yes of course the localhost is running the pgsql server and that port
is allowed!
> You should consider whether that's because a checkpoint is happening at
> that point. You didn't mention anything about your disk+controller
> information to have an idea how likely that is. Consider increasing
> checkpoint_warning=3600 so that you'll always get a note in the logs when
> a checkpoint happens; if those line up with your client disconnects that
> will be telling you something.
>
I am not sure what checkpoint stuff means. But I added that entry, and
now my log has ONLY this:
LOG: test message did not get through on socket for statistics collector
LOG: disabling statistics collector for lack of working socket
LOG: database system was shut down at 2008-02-14 17:53:13 CST
LOG: checkpoint record is at 8/E4BE7CF8
LOG: redo record is at 8/E4BE7CF8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/296662974; next OID: 89700
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system is ready
> On the logging size, you may want to also enable
> log_min_duration_statement ; around 500 (milliseconds) would be a
> reasonable starting value. That will show you what queries are taking a
> long time to handle.
I have this at 5000. I think I first want to track those that take
more than 5 seconds. But for now, the log is useless as mentioned
above.
> Be aware that when 8.2.3 was released, 8.2 had only been out for two
> months. There's another 11 months worth of accumulated bug fixes in
> 8.2.6, including some that can cause the server to slow or crash. It's
> not a difficult upgrade (no changes to the database) and you should
> consider it. There are plenty of known and already fixed problems in
> 8.2.3 you could be running into.
Thanks, I can do that, but the upgrade process is not very simple or
automated and will take backup of database and all that rigmarole.Last
time I remember, I had to seek help from this forum to do that simple
task, because something had gone remiss.
Is there an easy RPM method of upgrading postgresql without
backingup/restoring etc? I am on CentOS 4.
> > max_connections = 150
> > maintenance_work_mem = 512MB
> > shared_buffers = 330MB
> > work_mem = 100MB
>
> That's a really high setting for work_mem with this many connections; are
> you aware that combination can easily use 15GB of RAM?
I didn't know that, but it had been working for over a year. I have
4GB of RAM. I have changed this now to 10MB, the work_mem, but that
isn't helping.
I'd appreciate any other info. Thanks!
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
