Re: xlog filename formatting functions in recovery

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog filename formatting functions in recovery
Date: 2012-07-03 16:37:08
Message-ID: CAAZKuFb82mOiHnA6i+3vGXLx0CXyZe96ngfyEKo-72QUBx3oHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 3, 2012 at 5:30 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jul 3, 2012 at 8:16 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Tuesday, July 3, 2012, Robert Haas wrote:
>>> On Tue, Jul 3, 2012 at 6:43 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
>>> wrote:
>>> >>(added to commitfest:
>>> >> https://commitfest.postgresql.org/action/patch_view?id=888)
>>> > It seems you have added it in current commit fest.
>>> > Shouldn't it be added for next CF.
>>>
>>> Yep. The current CF has been closed to new submissions for two and a
>>> half weeks.
>>
>> Might this be something to consder for 9.2, though? It could be considered a
>> bugfix.
>>
>>> On the substance of the patch, I believe the reason why this is
>>> currently disallowed is because the TLI is implicitly taken from the
>>> running system, and on the standby that might be the wrong value.
>>>
>>> I might be misremembering.
>>
>> That is, however, assuming that this part is not true. I don't recall for
>> sure, but I have a feeling it might be correct. In which case a much bigger
>> patch is needed, and definitely not something for 9.2...
>
> Even if we were to conclude that the argument about TLIs is not valid,
> I'd be very reluctant to slip something like this into 9.2, because we
> have no time left to recant if it later turns out that there's some
> other reason why it's not a good idea. Removing error checks is one
> of those things that you want to try to get done early in the release
> cycle, because the consequences are sometimes difficult to foresee,
> and you may not find out why it was a bad idea until users start
> complaining.

Ah. The placement in that particular commitfest was an oversight. I'll move it.

--
fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-07-03 16:46:13 Re: User-Id Tracking when Portal was started
Previous Message Andres Freund 2012-07-03 16:36:51 Re: enhanced error fields