pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPostgres recovery time
2+ messages / 2 participants
[nested] [flat]
* Postgres recovery time
@ 2005-11-14 15:34 Piccarello, James (James) <jpicc@avaya.com>
2005-11-14 21:41 ` Re: Postgres recovery time David Boreham <david_list@boreham.org>
0 siblings, 1 reply; 2+ messages in thread
From: Piccarello, James (James) @ 2005-11-14 15:34 UTC (permalink / raw)
To: pgsql-performance
Does anyone know what factors affect the recovery time of postgres if it does not shutdown cleanly? With the same size database I've seen times from a few seconds to a few minutes. The longest time was 33 minutes. The 33 minutes was after a complete system crash and reboot so there are a lot of other things going on as well. 125 seconds was the longest time I could reproduce by just doing a kill -9 on postmaster.
Is it the size of the transaction log? The dead space in files?
I'm running postges 7.3.4 in Red Hat 8.0. Yes, yes I know it's crazy but for a variety of reasons upgrading is not currently feasible.
Jim
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Postgres recovery time
2005-11-14 15:34 Postgres recovery time Piccarello, James (James) <jpicc@avaya.com>
@ 2005-11-14 21:41 ` David Boreham <david_list@boreham.org>
0 siblings, 0 replies; 2+ messages in thread
From: David Boreham @ 2005-11-14 21:41 UTC (permalink / raw)
To: Piccarello, James (James) <jpicc@avaya.com>; +Cc: pgsql-performance
Piccarello, James (James) wrote:
> Does anyone know what factors affect the recovery time of postgres if
> it does not shutdown cleanly? With the same size database I've seen
> times from a few seconds to a few minutes. The longest time was 33
> minutes. The 33 minutes was after a complete system crash and reboot
> so there are a lot of other things going on as well. 125 seconds was
> the longest time I could reproduce by just doing a kill -9 on postmaster.
>
> Is it the size of the transaction log? The dead space in files?
>
I don't know much about postgresql, but typically WAL mechanisms
will exhibit recovery times that are bounded by the amount of log record
data written since the last checkpoint. The 'worst' case will be where
you have continuous writes to the database and a long checkpoint
interval. In that case many log records must be replayed into the
data files upon recovery. The 'best' case would be zero write transactions
since the last checkpoint. In that case recovery would be swift since
there are no live records to recover. In your tests you are probably
exercising this 'best' or near best case.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2005-11-14 21:41 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-11-14 15:34 Postgres recovery time Piccarello, James (James) <jpicc@avaya.com>
2005-11-14 21:41 ` David Boreham <david_list@boreham.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox