Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
| От | Melanie Plageman |
|---|---|
| Тема | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
| Дата | |
| Msg-id | CAAKRu_a04jbDACwzRYwzDND31aPyf7Yvz9TAZrTr=+F5bK1aVA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) (Chao Li <li.evan.chao@gmail.com>) |
| Список | pgsql-hackers |
On Mon, Dec 22, 2025 at 7:01 PM Chao Li <li.evan.chao@gmail.com> wrote: > > > On Dec 23, 2025, at 01:57, Melanie Plageman <melanieplageman@gmail.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
В списке pgsql-hackers по дате отправления: