"show post detail" shows Post state as "State recovery" and messages do not seem to be posting to (41016)

The status shows that post is running but messages are not posted. "Show post detail" indicates that it is in a recovery state. The successive snapshots of this command do not seem to indicate any progress as far as the offset or # of messages posted is concerned. The question arises as to whether to intervene at this time or let the issue resolve itself out. The following output illustrates this:

sp_ctrl (crmrepdb02:2103)> show post queue Queuename detail

Host : crmrepdb02.isus.xyz.com
Source : o.CRP01 Queue : Queuename

Operations
Target Status Posted Since Total

Backlog
---------- --------------- ---------- ------------------ ----------
----------
o.CRR02 Running 2 25-Sep-07 17:21:08 2210308
2141021

Last operation posted:
Redo log: 214408 Log offset: 1515433672
INSERT in "XYZ"."XYZ_SRLOG_ADD_AUDIT_COLMS" at 09/25/07
13:22:41

Post state : State recovery
Activation Id : 62

Current transaction Id : 9
ID of blocking transaction : 0
Number of open transactions : 26
Number of messages read released : 42143147

Operations posted : 2
Transactions posted : 0

Insert operations : 2
Update operations : 0
Delete operations : 0

Key cache hit count : 0

SQL cache hit count : 0 %

sp_ctrl (crmrepdb02:2103)> /

Host : crmrepdb02.isus.xyz.com
Source : o.CRP01 Queue : Queuename

Operations
Target Status Posted Since

Post is in recovery.

The recovery can be caused by a number of issues, such as abnormal shutdown of a process, queue corruption, user errors like wrong entry in paramdb, etc, among others. Some of them like abnormal shutdown will not cause the recovery to be incomplete meaning that the recovery will eventually finish. During recovery the Post will get rid of certain messages in the queue that it has already applied to the target database and for some reasons they have not been readreleased from the queue, something it will normally do after ascertaining that the messages have been applied. If recovery finishes successfully, the Post will start working normally and you will see the # of transactions posted keep increasing progressively when you issue "show post detail"

Before intervening, one may want to look into the target's $SP_SYS_VARDIR/log directory and see if the log file named *recover* is growing. If it keeps growing, wait for it to stop growing. The key here is patience. Once it stops growing, one may want to see if Post is processing normally and if so, there are no issues. If not, some intervention may be necessary and Support can be contacted for taking another look.