Re: Parameter name standby_mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parameter name standby_mode
Date: 2010-04-01 01:19:38
Message-ID: z2k603c8f071003311819y70a1c52eufeec55f7383c1b6b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 31, 2010 at 9:01 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Agreed. But what log message is repeated depends on the situation.
> So message without any location might be output. BTW, In my testing,
> the following message was repeated.
>
>    LOG:  invalid magic number 0000 in log file 0, segment 14, offset 9617408

Yeah, that's a pain in the neck. We need to think about a way to
avoid any of these messages repeating. Not sure how, off the top of
my head.

>> Should we make it shut down if it can't immediately read enough WAL to
>> get to a consistent state, or just figure it's the user's job to fix
>> it?
>
> I think that it's difficult for the user to fix it. So I agree to shut
> down the server in that case, i.e., throw a FATAL when an invalid WAL
> record is found and recovery hasn't reached the safe starting point
> even if neither primary_conninfo nor restore_command is given.

I think that's reasonable. It's not like this should cause any
problem for the user: they can add the missing WAL while the server is
down just as well as they could if it were up, and Hot Standby isn't
going to come up anyway. But I could possibly be persuaded to change
my mind on this one, if someone feels strongly otherwise.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-04-01 01:31:39 Re: pgindent excluded files list
Previous Message Bruce Momjian 2010-04-01 01:19:21 Re: [SPAM]Re: Questions about 9.0 release note