Re: forcing a rebuild of the visibility map
От | Robert Haas |
---|---|
Тема | Re: forcing a rebuild of the visibility map |
Дата | |
Msg-id | CA+TgmoY4EgOwCqTKoShirXSA8T5osDOkkvPYtKWzp1z_1xqeLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: forcing a rebuild of the visibility map (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: