Thread: help .. calling VACUUM FULL ANALYSE via JDBC make my production server restarting ?!?!?!? Please help :-(

Hi all,

  I just try to put my first postgresql server in production... and *(^&% it not easy...  I am in a fix/tweak/optimize
cyclefor more than a month.  Normal but I be so happy when everithing will be stable ... so that was I!  Sorry I work
aloneso need to talk sometime ;-) 


My new problem: the doSchemaMaintenance (in the stack trace below) calls a VACUUM FULL ANALYSE on the db.  It seems
thatthis make Postgresql close the connection and rebooted?!?!   

It seems to be an intermitant problem since I launch again the command this morning and it works without problems.

Any idea what is the problem?  Is that a good idea to call vacuum via JDBC or it's just a plan to ran into problems?

Is that a common behavior that Postgresql reboot like this?  For now I don't think so .. an I need to restart the
applicationeach time:-( 

Any help will be appreciated!
Thanks
/David


com.davecorp.webos.Manager

Error during sql: The backend has broken the connection. Possibly the action you have attempted has caused it to close.

org.postgresql.util.PSQLException: The backend has broken the connection. Possibly the action you have attempted has
causedit to close.    at com.ibatis.db.sqlmap.MappedStatement.executeUpdate(MappedStatement.java:426)    at
com.davecorp.webos.dao.DaoSupport.updateObject(DaoSupport.java:287)   at
com.davecorp.webos.dao.DaoSupport.updateObject(DaoSupport.java:274)   at
com.davecorp.webos.dao.SchemaUtilDaoImpl.doSchemaMaintenance(SchemaUtilDaoImpl.java:41)   at
com.davecorp.webos.schemaManager.SchemaManager.doSchemaMaintenance(SchemaManager.java:297)   at
com.davecorp.webos.commandManager.handler.DoDbMaintenanceHandler.processCommand(DoDbMaintenanceHandler.java:29)   at
com.davecorp.webos.commandManager.CommandManagerImpl$CommandDaemon.run(CommandManagerImpl.java:146)


ing the sql file: resources/order/dropConstraint_application.sql

org.postgresql.util.PSQLException: A connection error has occurred: org.postgresql.util.PSQLException: FATAL: the
databasesystem is starting up 
    at org.postgresql.jdbc1.AbstractJdbc1Connection.openConnectionV3(AbstractJdbc1Connection.java:337)    at
org.postgresql.jdbc1.AbstractJdbc1Connection.openConnection(AbstractJdbc1Connection.java:214)   at
org.postgresql.Driver.connect(Driver.java:139)   at
org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:82)   at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:300)   at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816)   at
org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:119)   at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:140)   at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:518)   at
com.davecorp.webos.connectionFactory.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:111)   at
com.davecorp.webos.connectionFactory.ConnectionFactory.getConnection(ConnectionFactory.java:42)   at
com.davecorp.webos.dao.Dao.executeSqlFile(Dao.java:232)   at com.davecorp.webos.dao.Dao.notificationEvent(Dao.java:207)
  at com.davecorp.webos.notification.NotificationSupport.fireEvent(NotificationSupport.java:57)    at
com.davecorp.webos.schemaManager.SchemaManager.reloadConstraints(SchemaManager.java:266)   at
com.davecorp.webos.schemaManager.SchemaManager.doSchemaMaintenance(SchemaManager.java:304)   at
com.davecorp.webos.commandManager.handler.DoDbMaintenanceHandler.processCommand(DoDbMaintenanceHandler.java:29)   at
com.davecorp.webos.commandManager.CommandManagerImpl$CommandDaemon.run(CommandManagerImpl.java:146)

On Fri, 29 Apr 2005, David Gagnon wrote:

> My new problem: the doSchemaMaintenance (in the stack trace below) calls
> a VACUUM FULL ANALYSE on the db.  It seems that this make Postgresql
> close the connection and rebooted?!?!

Anything involving rebooting is not a JDBC issue.  You'll need to check
the server logs and see what happened on that side of things.

Kris Jurka