On Mon, Jun 20, 2016 at 4:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I also don't see why it's a good idea to have knowledge about how to
>> truncate the visibility map outside of visibilitymap.c. Having that in a
>> contrib module just seems like a modularity violation.
>
> That seems like a pretty good argument.
I agree that's a good argument but it passes over one or two points
which motivated my approach. Most of the work of truncating the
visibility map is, in fact, encapsulated by visibilitymap_truncate, so
the only knowledge we're exporting to the contrib module is what WAL
record to emit. I put that in the caller of visibilitymap_truncate
because the only existing caller of visibilitymap_truncate is
RelationTruncate, which also knows what WAL record to emit on behalf
of visibilitymap.c. So I don't think I've exported any more knowledge
from visibilitymap.c than was the case previously.
That having been said, if somebody wants to whack this around, I am
not going to put up a big fight.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company