On Mon, Dec 22, 2021 at 6:14 PM [email protected]
<[email protected]> wrote:
>
> Attached the new patch v19.
>
I have a question on the v19-0002 patch:
When I tested for this patch, I found pg_stat_subscription_workers has some
unexpected data.
For example:
[Publisher]
create table replica_test1(a int, b text); create publication pub1 for table
replica_test1;
create table replica_test2(a int, b text); create publication pub2 for table
replica_test2;
[Subscriber]
create table replica_test1(a int, b text); create subscription sub1 CONNECTION
'dbname=postgres' publication pub1;
create table replica_test2(a int, b text); create subscription sub2 CONNECTION
'dbname=postgres' publication pub2;
[Publisher]
insert into replica_test1 values(1,'1');
[Subscriber]
select * from pg_stat_subscription_workers;
-[ RECORD 1 ]------+------
Subid | 16389
subname | sub1
subrelid |
commit_count | 1
...
-[ RECORD 2 ]------+------
subid | 16395
subname | sub2
subrelid |
commit_count | 1
...
I originally expected only one record for "sub1".
I think the reason is apply_handle_commit() always invoke
pgstat_report_subworker_xact_end().
But when we insert data to replica_test1 in publish side:
[In the publish]
pub1's walsender1 will send three messages((LOGICAL_REP_MSG_BEGIN,
LOGICAL_REP_MSG_INSERT and LOGICAL_REP_MSG_COMMIT))
to sub1's apply worker1.
pub2's walsender2 will also send two messages(LOGICAL_REP_MSG_BEGIN and
LOGICAL_REP_MSG_COMMIT)
to sub2's apply worker2. Because inserted table is not published by pub2.
[In the subscription]
sub1's apply worker1 receive LOGICAL_REP_MSG_COMMIT,
so invoke pgstat_report_subworker_xact_end to increase commit_count of
sub1's stats.
sub2's apply worker2 receive LOGICAL_REP_MSG_COMMIT,
it will do the same action to increase commit_count of sub2's stats.
Do we expect these commit counts which come from empty transactions ?
Regards,
Wang wei
