Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date: 2025-12-23 01:18:05
Message-ID: CAAKRu_a04jbDACwzRYwzDND31aPyf7Yvz9TAZrTr=+F5bK1aVA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 22, 2025 at 7:01 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > On Dec 23, 2025, at 01:57, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> >
> > My hesitation is that visibilitymap_set() is in a header file and
> > could be used by extensions/forks, etc. Adding more information by
> > changing a return value from void to non-void doesn't have any
> > negative effect on those potential callers. But taking away a return
> > value is more likely to affect them in a potentially negative way.
> >
> > However, I'm significantly changing the signature in this release, so
> > everybody that used it will have to change their code completely
> > anyway. Also, I just added a return value for visibilitymap_set() in
> > the previous release (18). Historically, it returned void. So, I've
> > gone with your suggestion.
>
> From a previous patch, I learned from Peter Eisentraut that “We don't care about ABI changes in major releases.”, see:

Right, it is totally okay to change function APIs in a major release.
My point was not that it wasn't allowed but that if people are getting
useful information returned from that function, or if we think we
might want that information again in the future, we should think twice
before changing it. But, in this case, I think we don't need to worry
about it.

- Melanie

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shixin Wang 2025-12-23 01:25:27 Re: Fix wrong reference in pg_overexplain's doc
Previous Message Yugo Nagata 2025-12-23 01:02:17 Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM