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
