On Tue, Jan 17, 2017 at 4:46 PM, Stephen Frost <sfrost@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