On 13.04.25 21:30, Jelte Fennema-Nio wrote:
On Fri Apr 4, 2025 at 7:34 PM CEST, Heikki Linnakangas wrote:
Let's move that 'in_restore_command' business to the caller. It's
weird modularity for the function to implicitly behave differently for
some callers.
I definitely agree with the sentiment, and it was what I originally
planned to do. But then I went for this approach anyway because commit
8fb13dd6ab5b explicitely moved all code except for the actual call to
system() out of the PreRestoreCommand()/PostRestoreCommand() section
(which is also described in the code comment).
So I didn't move the the in_restore_command stuff to the caller, and
improved the function comment to call out this unfortunate coupling.
And 'wait_event_info' should only affect pgstat reporting, not actual
behavior.
Given that we need to keep the restore command stuff in this function, I
think the only other option is to add a dedicated argument for the
restore command stuff, like "bool is_restore_command". But that would
require every caller, except for the restore command, to pass an
additional "false" as an argument. To me the additionaly noise that that
adds seems like a worse issue than the non-purity we get by
piggy-backing on the wait_event_info argument.
I don't feel good about the function name. How about pg_system() or
something?
This patch set is showing compiler warnings because pg_system() wasn't
properly declared where needed. Please provide an update that builds
cleanly.
Also, it appears the patch for pgbench disappeared from the series. Was
that intentional?
