Hi hackers, BACKGROUND:
The logical replication has different worker "types" (e.g. apply leader, apply parallel, tablesync). They all use a common structure called LogicalRepWorker, but at times it is necessary to know what "type" of worker a given LogicalRepWorker represents. Once, there were just apply workers and tablesync workers - these were easily distinguished because only tablesync workers had a valid 'relid' field. Next, parallel-apply workers were introduced - these are distinguishable from the apply leaders by the value of 'leader_pid' field. PROBLEM: IMO, deducing the worker's type by examining multiple different field values seems a dubious way to do it. This maybe was reasonable enough when there were only 2 types, but as more get added it becomes increasingly complicated. SOLUTION: AFAIK none of the complications is necessary anyway; the worker type is already known at launch time, and it never changes during the life of the process. The attached Patch 0001 introduces a new enum 'type' field, which is assigned during the launch. ~ This change not only simplifies the code, but it also permits other code optimizations, because now we can switch on the worker enum type, instead of using cascading if/else. (see Patch 0002). Thoughts? ------ Kind Regards, Peter Smith. Fujitsu Australia
v1-0001-Add-LogicalRepWorkerType-enum.patch
Description: Binary data
v1-0002-Switch-on-worker-type.patch
Description: Binary data
