On Sat, Feb 19, 2022 at 9:37 AM Andres Freund <and...@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.
