Re: New VACUUM FULL
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers@postgresql.org
Date: 2010-01-04T20:51:32Z
Lists: pgsql-hackers
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