Re: Design of pg_stat_subscription_workers vs pgstats

On Sun, Feb 20, 2022 at 10:10 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Sat, Feb 19, 2022 at 10:35 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Sat, Feb 19, 2022 at 9:37 AM Andres Freund <andres(at)anarazel(dot)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 would also like to mention that in some cases, sync workers also
> behaves like apply worker (after initial sync till it catches up with
> the apply worker) and try to stream and apply changes similar to apply
> worker. The error during that phase will be no different than the
> apply worker. One idea to make the separation more obvious is to
> introduce 'worker_type' column similar to backend_type in
> pg_stat_activity which will tell whether it is an apply worker or a
> table sync worker.
>
>
The point isn't to make the separation more obvious by specifying which
worker type is doing the work. It is to make the concept of worker type
(and identity) irrelevant. The end user cannot (and should not be able to)
address individual workers - only the subscription.

Even while a sync worker is in synchronization mode (as opposed to whatever
mode comes before synchronization mode) it still only affects a single
table. To the end user the distinction between the two modes is immaterial.

The statement "will be no different than the apply worker" doesn't make
sense to me given that in a multiple-table subscription (the only kind
where this matters...) you will have multiple table sync workers in
synchronization mode and they both cannot behave identically to an apply
worker otherwise they would step on each other's toes. That two different
table-specific updates produce the same error shouldn't be a problem if
that is indeed what happens (though if the error is on tableA having the
worker for tableB report the tableA error would be odd - but not
problematic).

I'll admit I don't fully understand the details of this particular
synchronization interaction but I'm not see how the discussion of "errors
during table-specific updates" vs "errors during whole transaction
application" can be affected by it.

David J.