Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Wed, Jul 31, 2024 at 04:49:54PM +0300, Alexander Korotkov wrote:
> On Mon, Jul 29, 2024 at 7:20 PM Robert Haas <robertmhaas@gmail.com> wrote:
>> I support that idea in general but felt it was overkill in this case:
>> it's new code, and there was only one existing caller of the function
>> that got refactored, and I'm not a huge fan of cluttering the git
>> history with a bunch of tiny little refactoring commits to fix a
>> single bug. I might have changed it if I'd seen this note before
>> committing, though.
>
> I understand your point.  I'm also not huge fan of a flood of small
> commits.  Nevertheless, I find splitting refactoring from other
> changes generally useful.  That could be a single commit of many small
> refactorings, not many small commits.  The point for me is easier
> review: you can expect refactoring commit to contain "isomorphic"
> changes, while other commits implementing material logic changes.

For review, it also tends to matter a lot to me, especially if the
same areas of code are changed across multiple commits.  That's more
annoying for authors as the splits are annoying to maintain.  For a
single caller introduced, what Robert has done is fine IMO.

> But that might be a committer preference though.

I tend to prefer refactorings if it comes to a cleaner git history,
still that's always case-by-case, and all of us have our own habits.
--
Michael