* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jan 17, 2017 at 11:27 AM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > > On 1/15/17 11:40 PM, Fujii Masao wrote: > >> This change may confuse the users who run "pg_ctl start" to perform a crash > >> recovery, archive recovery and standby server (with hot_standby=off) > >> because > >> "pg_ctl start" would not return so long time. > > > > Well, this change was made because the previous behavior confused people > > as well, because pg_ctl would return before it was actually done. > > > > The new state shouldn't be confusing because pg_ctl prints out progress > > messages. > > 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. > 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? 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. Now, perhaps the init process needs to be adjusted so that the progress reports from pg_ctl are seen by the user, but that's outside of PG. Thanks! Stephen
signature.asc
Description: Digital signature
