On Mon, Jun 20, 2016 at 4:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
