From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Masahiko Sawada <sawada.mshk@gmail.com>,
        Andres Freund <andres@anarazel.de>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Reviewing freeze map code
In-reply-to: 
 <CA+TgmoanNrWGteux-ZiNbXvQ0vJT6k0q_guA-WQQ-_Q0uycUQg@mail.gmail.com>
References: 
 <CA+TgmoZ2rW7sbx5=a=tWQM3_tH4codgjsKz7WF_pCqfEveJn6g@mail.gmail.com>
 <20160606141815.GA387566@alvherre.pgsql>
 <CA+TgmoanNrWGteux-ZiNbXvQ0vJT6k0q_guA-WQQ-_Q0uycUQg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 06 Jun 2016 10:34:03 -0400"
Date: Mon, 06 Jun 2016 11:00:52 -0400
Message-ID: <17049.1465225252@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> I'm intuitively sympathetic to the idea that we should have an option
> for this, but I can't figure out in what case we'd actually tell
> anyone to use it.  It would be useful for the kinds of bugs listed
> above to have VACUUM (rebuild_vm) to blow away the VM fork and rebuild
> it, but that's different semantics than what we proposed for VACUUM
> (even_frozen_pages).  And I'd be sort of inclined to handle that case
> by providing some other way to remove VM forks (like a new function in
> the pg_visibilitymap contrib module, maybe?) and then just tell people
> to run regular VACUUM afterwards, rather than putting the actual VM
> fork removal into VACUUM.

There's a lot to be said for that approach.  If we do it, I'd be a bit
inclined to offer an option to blow away the FSM as well.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers