On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: >> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada <sawada.m...@gmail.com> >>> wrote: >>>>> Can you submit that part as a separate patch? >>>> >>>> Attached. >>> >>> Thanks, committed. >>> >>>>>> I'm address the review comment of 7087166 commit, and will post the >>>>>> patch. >>>>> >>>>> When? >>>> >>>> On Saturday. >>> >>> Great. Will that address everything for this open item, then? >>> >> >> Attached patch for commit 7087166 on another mail. >> I think that only the test tool for visibility map is remaining and >> under the discussion. >> Even if we have verification tool or function for visibility map, we >> cannot repair the contents of visibility map if we turned out that >> contents of visibility map is something wrong. >> So I think we should have the way that re-generates the visibility map. >> For this purpose, doing vacuum while ignoring visibility map by a new >> option or new function is one idea. >> But IMHO, it's not good idea to allow a function to do vacuum, and >> expanding the VACUUM syntax might be somewhat overkill. >> >> So other idea is to have GUC parameter, vacuum_even_frozen_page for example. >> If this parameter is set true (false by default), we do vacuum whole >> table forcibly and re-generate visibility map. >> The advantage of this idea is that we don't necessary to expand VACUUM >> syntax and relatively easily can remove this parameter if it's not >> necessary anymore. >> > > Attached is a sample patch that controls full page vacuum by new GUC > parameter.
Don't we want a reloption for that? Just wondering... -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
