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?
