On Thu, Oct 10, 2019 at 5:52 AM Peter Eisentraut
wrote:
>
> On 2019-09-30 03:48, Fujii Masao wrote:
> > Also we need to do the same thing for other recovery options like
> > restore_command. Attached is the patch which makes crash recovery
> > ignore restore_command and recovery_end_command.
>
> T
On 2019-09-30 03:48, Fujii Masao wrote:
> Also we need to do the same thing for other recovery options like
> restore_command. Attached is the patch which makes crash recovery
> ignore restore_command and recovery_end_command.
This patch looks correct to me.
Do we need to handle archive_cleanup_c
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 9, 2019 at 8:42 AM Stephen Frost wrote:
> > If anything, what we should be doing here is throwing a WARNING or
> > similar that these settings don't make sense, because we aren't going
> > through recovery, and blank them out.
On Wed, Oct 9, 2019 at 8:42 AM Stephen Frost wrote:
> You're going to be really confused when you realize that, sure, it's
> set, but we just completely ignored it ...
No, I'm not, because I expect that settings will only take effect for
operations to which they apply. As Fujii Masao also pointed
Greetings,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Wed, Oct 9, 2019 at 1:02 AM Stephen Frost wrote:
> > * Fujii Masao (masao.fu...@gmail.com) wrote:
> > > On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
> > > > Having these options end up set but then hacking all of the other code
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost wrote:
> > From a user
> > perspective, what happens when you've started up PG as a primary, since
> > you don't have a signal file in place to indicate that you're doing
> > recovery, and you h
On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost wrote:
> From a user
> perspective, what happens when you've started up PG as a primary, since
> you don't have a signal file in place to indicate that you're doing
> recovery, and you have a recovery_target set, so some user does
> "show recovery_targe
On Wed, Oct 9, 2019 at 1:02 AM Stephen Frost wrote:
>
> Greetings,
>
> * Fujii Masao (masao.fu...@gmail.com) wrote:
> > On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
> > > Having these options end up set but then hacking all of the other code
> > > that looks at them to check if we're actu
Greetings,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
> > Having these options end up set but then hacking all of the other code
> > that looks at them to check if we're actually in recovery or not would
> > end up being both confusing to u
On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
>
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Oct 7, 2019 at 9:14 AM Fujii Masao wrote:
> > > Agreed, too. Do you have any idea to implement that? I've not found out
> > > "smart" way to do that yet.
> > >
> > > On
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 7, 2019 at 9:14 AM Fujii Masao wrote:
> > Agreed, too. Do you have any idea to implement that? I've not found out
> > "smart" way to do that yet.
> >
> > One idea is, as Michael suggested, to use SetConfigOption() for all the
>
On Mon, Oct 7, 2019 at 9:14 AM Fujii Masao wrote:
> Agreed, too. Do you have any idea to implement that? I've not found out
> "smart" way to do that yet.
>
> One idea is, as Michael suggested, to use SetConfigOption() for all the
> archive recovery parameters at the beginning of the startup proces
On Fri, Oct 4, 2019 at 6:09 PM Michael Paquier wrote:
>
> On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote:
> > * David Steele (da...@pgmasters.net) wrote:
> >> On 9/28/19 1:26 PM, Fujii Masao wrote:
> >>> There might be some recovery parameters that we can safely use
> >>> even in cr
On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote:
> * David Steele (da...@pgmasters.net) wrote:
>> On 9/28/19 1:26 PM, Fujii Masao wrote:
>>> There might be some recovery parameters that we can safely use
>>> even in crash recovery, e.g., maybe recovery_end_command
>>> (now, you can se
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 9/28/19 1:26 PM, Fujii Masao wrote:
> > On Sun, Sep 29, 2019 at 12:51 AM David Steele wrote:
> >
> > Yeah, more checks would be necessary. IMO easy fix is to forbid not only
> > recovery target parameters but also any recovery parameter
On Mon, Sep 30, 2019 at 6:59 AM Peter Eisentraut
wrote:
>
> On 2019-09-29 18:36, Fujii Masao wrote:
> > Yes, but ArchiveRecoveryRequested should be checked instead of
> > InArchiveRecovery, I think. Otherwise recovery targets would take effect
> > when recovery.signal is missing but backup_label e
On 2019-09-29 18:36, Fujii Masao wrote:
> Yes, but ArchiveRecoveryRequested should be checked instead of
> InArchiveRecovery, I think. Otherwise recovery targets would take effect
> when recovery.signal is missing but backup_label exists. In this case,
> InArchiveRecovery is set to true though Arch
On 2019-09-27 17:14, David Steele wrote:
> On 9/27/19 10:36 AM, Peter Eisentraut wrote:
>> On 2019-09-26 23:02, David Steele wrote:
>>> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
>>>
I don't know if recovery_target_timeline is actually useful to change in
standby mode.
>> OK, I have comm
On Sun, Sep 29, 2019 at 6:08 AM Peter Eisentraut
wrote:
>
> On 2019-09-28 19:45, Tom Lane wrote:
> > Maybe I'm misunderstanding, but I think that rather than adding error
> > checks that were not there before, the right path to fixing this is
> > to cause these settings to be ignored if we're doin
On 2019-09-28 19:45, Tom Lane wrote:
> Maybe I'm misunderstanding, but I think that rather than adding error
> checks that were not there before, the right path to fixing this is
> to cause these settings to be ignored if we're doing crash recovery.
That makes sense to me. Something like this (un
On 9/28/19 1:26 PM, Fujii Masao wrote:
> On Sun, Sep 29, 2019 at 12:51 AM David Steele wrote:
>
> Yeah, more checks would be necessary. IMO easy fix is to forbid not only
> recovery target parameters but also any recovery parameters (specified
> in recovery.conf in previous versions) in crash rec
Fujii Masao writes:
>> Agreed. Seems like that could be added to the patch above easily
>> enough. More checks would be needed to prevent the behaviors I've been
>> seeing in the other thread, but it should be possible to more or less
>> mimic the old behavior with sufficient checks.
> Yeah, mo
On Sun, Sep 29, 2019 at 12:51 AM David Steele wrote:
>
> On 9/28/19 10:54 AM, Fujii Masao wrote:
> > On Sat, Sep 28, 2019 at 2:01 AM David Steele wrote:
> >> On 9/27/19 11:58 AM, Fujii Masao wrote:
> >>>
> >>> Yes, recovery target settings are used even when neither backup_label
> >>> nor recover
On 9/28/19 10:54 AM, Fujii Masao wrote:
> On Sat, Sep 28, 2019 at 2:01 AM David Steele wrote:
>> On 9/27/19 11:58 AM, Fujii Masao wrote:
>>>
>>> Yes, recovery target settings are used even when neither backup_label
>>> nor recovery.signal exist, i.e., just a crash recovery, in v12. This is
>>> com
On Sat, Sep 28, 2019 at 2:01 AM David Steele wrote:
>
> On 9/27/19 11:58 AM, Fujii Masao wrote:
> > On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote:
> >>
> >> I think, at the very least, the fact that targeted recovery proceeds in
> >> the absence of recovery.signal represents a bug.
> >
> >
On 9/27/19 11:58 AM, Fujii Masao wrote:
> On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote:
>>
>> I think, at the very least, the fact that targeted recovery proceeds in
>> the absence of recovery.signal represents a bug.
>
> Yes, recovery target settings are used even when neither backup_labe
On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote:
>
> Hi Peter,
>
> On 9/27/19 10:36 AM, Peter Eisentraut wrote:
> > On 2019-09-26 23:02, David Steele wrote:
> >> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
> >>
> >>> I don't know if recovery_target_timeline is actually useful to change in
> >>
Hi Peter,
On 9/27/19 10:36 AM, Peter Eisentraut wrote:
> On 2019-09-26 23:02, David Steele wrote:
>> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
>>
>>> I don't know if recovery_target_timeline is actually useful to change in
>>> standby mode.
>
> OK, I have committed your original documentation p
On 2019-09-26 23:02, David Steele wrote:
> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
>> On 2019-09-25 22:21, David Steele wrote:
>>> While testing against PG12 I noticed the documentation states that
>>> recovery targets are not valid when standby.signal is present.
>>>
>>> But surely the excepti
On 9/26/19 4:48 PM, Peter Eisentraut wrote:
On 2019-09-25 22:21, David Steele wrote:
While testing against PG12 I noticed the documentation states that
recovery targets are not valid when standby.signal is present.
But surely the exception is recovery_target_timeline? My testing
confirms that
On 2019-09-25 22:21, David Steele wrote:
> While testing against PG12 I noticed the documentation states that
> recovery targets are not valid when standby.signal is present.
>
> But surely the exception is recovery_target_timeline? My testing
> confirms that this works just as in prior versions
On 9/26/19 5:55 AM, Fujii Masao wrote:
> On Thu, Sep 26, 2019 at 5:22 AM David Steele wrote:
>>
>> While testing against PG12 I noticed the documentation states that
>> recovery targets are not valid when standby.signal is present.
>
> Or that description in the doc is not true? Other recovery ta
On Thu, Sep 26, 2019 at 5:22 AM David Steele wrote:
>
> While testing against PG12 I noticed the documentation states that
> recovery targets are not valid when standby.signal is present.
Or that description in the doc is not true? Other recovery target
parameters seem to take effect even when st
33 matches
Mail list logo
