On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote:
>> >> 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).
>>
>> Isn't there some way we can tell if a server is an HS master, and
>> prevent VFI from being run?
>
> I'm proposing that VFI is only accessible by explicit request using new
> syntax; no existing code would call VFI.
>
> The VFI problems would only apply to system relations anyway, not to all
> tables.
>
> I propose we have a WARNING if VFI being run when recovery_connections =
> on, since I probably know what I'm doing if I go out of my way to use
> new syntax after presumably having read the manual.
I think I'd vote for throwing an ERROR. By the time you see the
WARNING it may be too late. Since this is only for emergencies, the
user can shut off recovery_connections first if they really need it.
> Just as a point of note, I'm worried that the act of removing VFI would
> introduce more bugs than leaving it alone; if its there we may as well
> keep it runnable.
>
> Changes required to remove it are at least these places
>
> * most of vacuum.c
> * visibility checks
> * heap tuple flags and xvac
> * nontransactional validation
> * minor points and follow up in >7 files, >12 places
Doesn't sound trivial.
...Robert
