On Mon, Jan 4, 2010 at 11:57 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > This is a more cautious approach. Completely removing VFI in this
>> > release is a big risk that we need not take; we have little to gain from
>> > doing so and putting it back again will be harder. I am always keen to
>> > push forwards when a new feature is worthwhile, but cleaning up code is
>> > not an important thing this late in release cycle.
>>
>> I don't have a strong opinion one way or the other on whether we
>> should remove VFI this release cycle, but I thought the reason why
>> there was pressure to do that was because we will otherwise need to
>> make changes to Hot Standby to cope with VFI.
>
> What I should have said, in addition: VFI will be kept as a non-default
> option, in case it is required. We will document that use of VFI will
> not work correctly with HS and that its use is deprecated and should be
> in emergencies only in any case. I will enjoy removing VFI when that
> eventually occurs, but its not a priority. (And if you think, why keep
> it? I'll say - how else can we run a VFI - not by a stored proc,
> certainly).
If we go this route, can we make it fail in a relatively detectable
way with Hot Standby? Like an error message that says "oh, crap, you
did a VFI, you need a new base backup"? Or will it do something
goofier than that?
I don't have an informed opinion on whether or not we should try to
remove VFI in this release, and I leave that discussion to yourself
and other people who are more qualified to speak to that issue than I
am. I am somewhat dismayed that there are not more people weighing in
on this, because it seems to me that this is a critical issue for the
forthcoming release, so we really need to make sure we have consensus
on the way forward NOW, not a month from now.
...Robert
