> > i think that somewhere in the docs the administators
> > should be advised to delete postmaster.pid automatically at boot
> > time ( for example at the same time when the files in /tmp are
> > deleted ).
> > This way, in case of an unexpected shutdown, postgresql would be
> > able to restart without any manual intervention.
> Well, this is a *BAD IDEA*. Suppose, for example, your data is corrupt in
> some special way, an due to your removal of the pid file, postmaster tries to
> recover the database automatically and probably destroys all or data part of
> the data. You would like to have been able to do a filseystem level backup
> first...
Ooopss... it seems like i am too optimistic about such situations.
Just wondering: if the database is so heavily damaged that the
postmaster would not be able to recover, are there any chances to
restore anything from a filesystem backup, manually ?
.........
Background:
- our team is working on a project for a small company.
- there will be one server and 3-4 clients
- It is the first time we use PostgreSQL.
- Little space.
- Many people around.
- No UPS (yet).
- unpredictable,untrained,desperate,'crazy' users
Possible problems:
- the users will need time to learn how to use the program
( until then they could do many mistakes, such as turning off the
server before leaving the office - without issueing the proper
shutdown command, but simply pushing the power switch. )
- someone might stumble over the cable and unplug the server by mistake.
Questions:
How resistent is PostgreSQL to such shocks?
Are there alternative solutions to handling unexpected shutdowns
automatically? (except deleting postmaster.pid at boot time)
Best wishes,
Adrian Maier
(am@fx.ro)
