The following step can help reproducing the problem:
1. Run "initinstance.sh" and get two instance, one publisher and one
subscriber, this script will create a subscription as well;
2. Run “createschema.sh” and create 1000 schemas, each schema has 100 tables;
3. Run “createpublication.sh” and create a huge publication, which
publishes 10000 tables;
4. Run “insert.sh” and insert exactly one tuple into each table
created in Step 2;
5. Run “insert into t values(1);” in publisher, and then we can found
it in subscriber;
6. Run “drop publication pub_t_large;” in publisher;
7. Run “insert into t values(1);” in publisher, and then we can not
find it in subscriber, cause the walsender has hanged in decoding Step
6’s XLOG;
PG Bug reporting form <noreply@postgresql.org> 于2022年12月13日周二 15:51写道：
>
> The following bug has been logged on the website:
>
> Bug reference: 17716
> Logged by: bowenshi
> Email address: zxwsbg12138@gmail.com
> PostgreSQL version: 13.9
> Operating system: centos
> Description:
>
> Dears, I have found a problem while using logical decoding. I have two
> publications, and the walsender process hang while decoding DROP PUBLICATION
> XLOG of another publication. The pstack looks like following:
>
> #0 0x00000000008b9c24 in hash_seq_search ()
> #1 0x00007fd14340590c in rel_sync_cache_publication_cb () from
> pgoutput.so
> #2 0x0000000000897a1a in CallSyscacheCallbacks ()
> #3 0x000000000073682e in ReorderBufferCommit ()
> #4 0x000000000072b988 in DecodeXactOp ()
> #5 0x000000000072bd52 in LogicalDecodingProcessRecord ()
> #6 0x000000000074d14f in XLogSendLogical ()
> #7 0x000000000074f562 in WalSndLoop ()
> #8 0x0000000000750322 in exec_replication_command ()
> #9 0x0000000000792301 in PostgresMain ()
> #10 0x000000000048854f in ServerLoop ()
> #11 0x000000000071b579 in PostmasterMain ()
> #12 0x000000000048948d in main ()
>
> When I user perl to analyze, it spend almost 99% time in `hash_seq_search`
> function.
>
> This problem can be reproduced , and I will send the shell script later.
>