Re: Design of pg_stat_subscription_workers vs pgstats

On 02.02.22 07:54, Amit Kapila wrote:
>>> Where do you propose to store this information?
>>
>>
>> pg_subscription_worker
>>
>> The error message and context is very important. Just make sure it is only non-null when the worker state is "syncing failed" (or whatever term we use).

We could name the table something like pg_subscription_worker_error, so
it's explicit that it is collecting error information only.

> Sure, but is this the reason you want to store all the error info in
> the system catalog? I agree that providing more error info could be
> useful and also possibly the previously failed (apply) xacts info as
> well but I am not able to see why you want to have that sort of info
> in the catalog. I could see storing info like err_lsn/err_xid that can
> allow to proceed to apply worker automatically or to slow down the
> launch of errored apply worker but not all sort of other error info
> (like err_cnt, err_code, err_message, err_time, etc.). I want to know
> why you are insisting to make all the error info persistent via the
> system catalog?

Let's flip this around and ask, why not? Tables are the place to store
data, by default.