On Tue, Jan 17, 2017 at 4:46 PM, Stephen Frost <sfr...@snowman.net> wrote: >> But what if we're restarting after, say, rebooting? Then there's >> nobody to see the progress messages, perhaps. The system just seems >> to take an eternity to return to the usual runlevel. > > Not unlike an fsck.
Right. That's why people developed journaled filesystems like ext3 and ext4 - because waiting for increasingly-large disks to be checked for errors sucked. And that made fsck times vastly lower and everyone said "huzzah". Because waiting for things to happen stinks, and people want to do as little of it as is reasonably possible. >> I saw the discussion on this thread, but I didn't realize that it >> meant that pg_ctl was going to wait for crash recovery, let alone >> archive recovery. That seems not good. > > I disagree. The database isn't done starting up until it's gone through > recovery. If there are other bits of the system which are depending on > the database being online, shouldn't they wait until it's actually > online to be started? They aren't necessarily depending on the database; they could be entirely unrelated. > Admittedly, such processes should probably be prepared to try > reconnecting to the database on a failure, but I don't see this as > really all that different from how a journaling filesystem operates. A journaling filesystem doesn't have a mode where it enters archive recovery mode and stays there permanently leaving the system in an unusable state. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
