From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Design of pg_stat_subscription_workers vs pgstats |
Date: | 2022-02-03 09:55:37 |
Message-ID: | b7bec04c-e1a7-6033-0835-e683f480869f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-02-03 10:54:10 | Re: UNIQUE null treatment option |
Previous Message | Fabien COELHO | 2022-02-03 09:44:11 | Re: Latest LLVM breaks our code again |