Re: Design of pg_stat_subscription_workers vs pgstats

On Sat, Feb 19, 2022 at 9:37 AM Andres Freund <andres@anarazel.de> wrote:

> IMO the type of information you'd want for apply failures is substantially
>
different enough from worker failures that I don't really see the temptation
> to put them in the same table.
>
>
It's an error message and a transaction LSN in both cases right now, along
with knowledge of whether said transaction only affects a single table
(relid is not null) or not (relid is null).  Do you have a concrete idea in
mind that would make this separation need more obvious?


> I also still think that _worker shouldn't be part of any of the naming
> here. It's an implementation detail that we use one worker for one
> tablesync
> etc. It'd make sense for one apply worker to sync multiple small tables,
> and
> it'd make a lot of sense for multiple apply workers to collaborate on
> syncing
> one large relation.
>

Good point.  The existing design doesn't actually require the "worker
status" concept I described; so let's not have worker be part of the name.

So basically separate the proposed pg_subscription_error table into two: a
pg_subscription_tablesync_error and pg_subscription_apply_error.  The
former having a relid field while the later does not. What fields belong on
each?

How about we have it both ways.  Two tables but provide a canonical view
union'ing them that a user can query to see whether any errors are
presently affecting their system?

David J.