On Sat, Jun 5, 2010 at 2:20 AM, Robert Haas wrote:
>> I've tried to keep this as similar as possible to the existing message while
>> making it less ambiguous about cause and effect.
>>
>> "If this has occurred more than once corrupt data might be the cause and you
>> might need to choose an ear
On Fri, Jun 4, 2010 at 8:21 PM, Florian Pflug wrote:
> On Jun 3, 2010, at 5:25 , Robert Haas wrote:
>> On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote:
Oh. Well, if that's the case, then I guess I lean toward applying the
patch as-is. Then there's no need for the caveat "and with
On Jun 3, 2010, at 5:25 , Robert Haas wrote:
> On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote:
>>> Oh. Well, if that's the case, then I guess I lean toward applying the
>>> patch as-is. Then there's no need for the caveat "and without manual
>>> intervention".
>>
>> That still leaves the
On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote:
>> Oh. Well, if that's the case, then I guess I lean toward applying the
>> patch as-is. Then there's no need for the caveat "and without manual
>> intervention".
>
> That still leaves the messages awfully ambiguous concerning the cause (data
On Jun 3, 2010, at 3:31 , Robert Haas wrote:
> On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug wrote:
>> On Jun 3, 2010, at 0:58 , Robert Haas wrote:
>>> But maybe the message isn't right the first time either. After all
>>> the point of having a write-ahead log in the first place is that we
>>> sh
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug wrote:
> On Jun 3, 2010, at 0:58 , Robert Haas wrote:
>> But maybe the message isn't right the first time either. After all
>> the point of having a write-ahead log in the first place is that we
>> should be able to prevent corruption in the event of
On Jun 3, 2010, at 0:58 , Robert Haas wrote:
> But maybe the message isn't right the first time either. After all
> the point of having a write-ahead log in the first place is that we
> should be able to prevent corruption in the event of an unexpected
> shutdown. Maybe the right thing to do is t
On Wed, Jun 2, 2010 at 5:39 PM, Heikki Linnakangas
wrote:
> On 02/06/10 23:50, Robert Haas wrote:
>>
>> First, is it appropriate to set the control file state to
>> DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as
>> opposed to archive recovery/SR)? My vote is no, but Heikki though
On 02/06/10 23:50, Robert Haas wrote:
First, is it appropriate to set the control file state to
DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as
opposed to archive recovery/SR)? My vote is no, but Heikki thought it
might be OK.
My logic on that is:
If the database is known to b
On Mon, May 17, 2010 at 4:33 AM, Fujii Masao wrote:
> On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
>> Hmm, OK, I think that makes sense. Would you care to propose a patch?
>
> Yep. Here is the patch.
>
> This patch distinguishes normal shutdown from unexpected exit, while the
> server is
On Tue, May 25, 2010 at 12:36 PM, Simon Riggs wrote:
> On Tue, 2010-05-25 at 19:12 +0900, Fujii Masao wrote:
>> On Mon, May 17, 2010 at 5:33 PM, Fujii Masao wrote:
>> > On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
>> >> Hmm, OK, I think that makes sense. Would you care to propose a patch
On Tue, 2010-05-25 at 19:12 +0900, Fujii Masao wrote:
> On Mon, May 17, 2010 at 5:33 PM, Fujii Masao wrote:
> > On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
> >> Hmm, OK, I think that makes sense. Would you care to propose a patch?
> >
> > Yep. Here is the patch.
> >
> > This patch distin
On Mon, May 17, 2010 at 5:33 PM, Fujii Masao wrote:
> On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
>> Hmm, OK, I think that makes sense. Would you care to propose a patch?
>
> Yep. Here is the patch.
>
> This patch distinguishes normal shutdown from unexpected exit, while the
> server is
On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
> Hmm, OK, I think that makes sense. Would you care to propose a patch?
Yep. Here is the patch.
This patch distinguishes normal shutdown from unexpected exit, while the
server is in recovery. That is, when smart or fast shutdown is requested
d
On Thu, May 13, 2010 at 1:28 AM, Fujii Masao wrote:
> On Thu, May 13, 2010 at 12:10 PM, Robert Haas wrote:
>> Hmm, it seems this is my night to rediscover the wisdom of your
>> previous proposals. I think that state would only be appropriate when
>> we shutdown after reaching consistency, not an
On Thu, May 13, 2010 at 12:10 PM, Robert Haas wrote:
> Hmm, it seems this is my night to rediscover the wisdom of your
> previous proposals. I think that state would only be appropriate when
> we shutdown after reaching consistency, not any shutdown during
> recovery. Do you agree?
No. When shu
On Wed, May 12, 2010 at 11:07 PM, Fujii Masao wrote:
> On Thu, May 13, 2010 at 10:01 AM, Robert Haas wrote:
>> When firing up a properly shut down HS slave, I get:
>>
>> LOG: database system was interrupted while in recovery at log time
>> 2010-05-12 20:35:24 EDT
>> HINT: If this has occurred m
On Thu, May 13, 2010 at 10:01 AM, Robert Haas wrote:
> When firing up a properly shut down HS slave, I get:
>
> LOG: database system was interrupted while in recovery at log time
> 2010-05-12 20:35:24 EDT
> HINT: If this has occurred more than once some data might be
> corrupted and you might ne
When firing up a properly shut down HS slave, I get:
LOG: database system was interrupted while in recovery at log time
2010-05-12 20:35:24 EDT
HINT: If this has occurred more than once some data might be
corrupted and you might need to choose an earlier recovery target.
But this is kind of an
19 matches
Mail list logo
