Hi, On 2022-02-03 13:33:08 +0900, Masahiko Sawada wrote: > I see that important information such as error-XID that can be used > for ALTER SUBSCRIPTION SKIP needs to be stored in a reliable way, and > using system catalogs is a reasonable way for this purpose. But it's > still unclear to me why all error information that is currently shown > in pg_stat_subscription_workers view, including error-XID and the > error message, relation OID, action, etc., need to be stored in the > catalog. The information other than error-XID doesn't necessarily need > to be reliable compared to error-XID. I think we can have > error-XID/LSN in the pg_subscription catalog and have other error > information in pg_stat_subscription_workers view. After the user > checks the current status of logical replication by checking > error-XID/LSN, they can check pg_stat_subscription_workers for > details.
The stats system isn't geared towards storing error messages and such. Generally it is about storing counts of events etc, not about information about a single event. Obviously there are a few cases where that boundary isn't that clear... IOW, storing information like: - subscription oid - retryable error count - hard error count - #replicated inserts - #replicated updates - #replicated deletes is what pgstats is for. But not - subscription oid - error message - xid of error - ... IMO the addition of the pg_stat_subscription_workers view needs to be reverted. Yes, there's some precedent in pg_stat_archiver. But that ship has sailed (it's released), and it's a much more limited issue. Just because we did a not great thing once isn't a reason to do a similar, but even less great, thing another time. Greetings, Andres Freund