Re: Logging parallel worker draught

On 23/06/2026 15:47, Benoit Lobréau wrote:
> Hi thanks for taking a look at this patch,
>

Yeah, I'd like to solve long-standing pain with a death-looping worker - it
happens frequently, for example, in logical replication. We should have some
statistics that allow DBAs to detect whether a bgworker is constantly restarting
without performing any work. So, your work is quite close to mine.

>> I wonder, what is the actual reason to report after the operation ended? What if
>> the operation has been interrupted? We will not see the report at all. Maybe it
>> is better to do after the launch: we successfully acquired worker slot, and
>> that's what we actually wanted to know, isn't it?
>
> At the beginning the patch did exactly that (at the node level), but it lead to
> many
> reports for the same query and it was suggested that query level results would be
> better.

I get what you mean. Parallel sections can be spread out in the query plan, and
Gather starts them in a lazy manner. Because of this, the number of unavailable
slots can change.
But with concurrent index building, it's different. In that case, you can report
the workers as soon as they start.

>
>> Also, I don't understand why log_parallel_workers has exactly these options, and
>> there is no documentation explaining the reasoning. Generally, I'd prefer the
>> log level here - it would be easier to write tests as well.
>
> For this feature, my idea was to have a way to get informations on parallelism
> during
> audits. Changing the log level would not be appropriate for this in my opinion.

What I meant is, if you just need to turn the feature on or off, you could use
log levels for more flexibility. Setting it to DEBUG5 will basically turn off
logging, while ERROR lets you write tests. You haven't written any tests yet,
have you?

--
regards, Andrei Lepikhov,
pgEdge