RE: [HACKERS] More postmaster troubles

Is there any documentation on database recovery.  I am new to Postgres.  I
really like what I see.  I have written a membership database application
for a NPO in New Mexico.  It is written in Access 97.  I want to migrate to
a real database engine and I am strongly considering Postgres.  I have
several questions:

1)    Is transaction logging available, how does it work, and how do I set
it up.  I have been through most of the on-line documentation several time
(available on the internet) and have not found anything that talks about
transaction logging.

2)    Database recovery.  If I make a back up at 10:00am and the database
goes south at 1:00pm, can I restore back to 10:00am and automatically
re-post any/all transactions that occurred between 10:00am and 1:00pm
without requiring the users to re-enter all their data?

3)    Is any working on mirroring or shadowing?  I would like to be able
have a backup database engine on a second back-up server get automatically
updated soon after an update is posted to the main server.

Thanks, Michael
-----Original Message-----From:    Tom Lane [SMTP:tgl@sss.pgh.pa.us]Sent:    Saturday, February 13, 1999 1:23 PMTo:
DarylW. DunbarCc:    pgsql-hackers@postgreSQL.orgSubject:    Re: [HACKERS] More postmaster troubles 
 
"Daryl W. Dunbar" <daryl@www.com> writes:> Thank you Tatsousan.  This patch will solve the dying process> problem when
Ireach MaxBackendId (which I increased from 64 to> 128).  However, I do not know what is causing the spiraling death
 
of> the processes in the first place. :(
Hmm.  I have noticed at least one place in the code where there is
anundocumented hard-wired dependency on MaxBackendId, to wit
MAX_PROC_SEMSin include/storage/proc.h which is set at 128.  Presumably it should
beequal to MaxBackendId (and I intend to fix that soon).  Evidently
thatparticular bug is not hurting you (yet) but perhaps there are
similarerrors elsewhere that kick in sooner.  Do you see the
spiraling-deathproblem if you run with MaxBackendId at its customary value of 64?
The log extract you posted before mentions "fputc() failed:
errno=32"which suggests an unexpected client disconnect during a transaction.I suspect the backend that gets that
disconnectis failing to clean
 
upproperly before exiting, and is leaving one or more locks locked.We don't have enough info yet to track down the
cause,but I suggestwe could narrow it down some by seeing whether the problem goes awaywith a lower MaxBackendId
setting.
(You might also want to work on making your clients more robust,but I'd like to see if we can solve the backend bug
first...)
 
            regards, tom lane