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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
