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.
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
-- Simon Riggs www.2ndQuadrant.com
