On 2016-06-18 11:56:51 -0400, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Sat, Jun 18, 2016 at 6:53 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> Andres, do you want to explain the nature of your concern further?
>
> > I am not in his mind, but my guess is that contrib modules are
> > sometimes used as template examples by other people, and encouraging
> > users to use those routines in modules would increase the risk to
> > misuse them, aka badly-formed records that could corrupt the system.
That's not it, no.
> If Andres' concern is that XLogInsert isn't a very stable API, maybe
> we could address that by providing some wrapper function that knows
> how to emit the specific kind of record that pg_visibility needs.
That's part of the concern I have, yes. It's pretty common that during
minor version updates contrib modules are updated before the main server
is restarted. Increasing the coupling on something as critical as WAL
logging doesn't strike me as a good idea.
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. To me this
should be a wal_log paramter to visibilitymap_truncate().
Andres