Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reviewing freeze map code
Date
Msg-id 17049.1465225252@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rename synchronous_standby_names?
Next
From: Robert Haas
Date:
Subject: Re: Problem with dumping bloom extension