On Thu, Apr 8, 2010 at 9:56 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote:
>> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
>> >
>> >> > I do. I see no reason to do the latter, ever, so should not be added to
>> >> > any TODO.
>> >>
>> >> Well, stopping recovery earlier would mean fewer locks, which would
>> >> mean a better chance for the read-only backends to finish their work
>> >> and exit quickly. But I'm not sure how much it's worth worrying
>> >> about.
>> >
>> > The purpose of the lock is to prevent access to objects when they are in
>> > inappropriate states for access. If we stopped startup and allowed
>> > access, how do we know that things are in sufficiently good state to
>> > allow access? We don't. If the Startup process is holding a lock then
>> > that is the only safe thing to do. Otherwise we might allow access to a
>> > table with a partially built index or other screw ups.
>>
>> Hmm. Good point. I guess you could really only stop the startup
>> process safely when it wasn't holding any locks anyhow - you couldn't
>> just kill it and have it release the locks.
>
> ... and if it isn't holding any locks at all, there is no reason to kill
> Startup first => no TODO item.
I think you could shut it down at the first point at which it is
holding no locks, rather than letting it continue recovering and
potentially retake some new locks. That would be more consistent with
the general idea of what a smart shutdown is supposed to be about. I
think the real question is whether it's worth the code complexity. I
suspect most people use fast shutdown most of the time anyway in
real-world applications.
...Robert