-
Title
Error Poster: Request for invalid column #, table OWNER.TABLE_NAME; cannot continue -
Description
The following errors are observed when Post errors out or core dumps:
Event_log:
Error 2019-04-23 04:27:17.032423 120597 4260759424 Poster: Request for invalid column #, table OWNER.TABLE_NAME; cannot continue (posting from o.sourcesid, queue name, to o.targetsid) [module osp]Error 2019-04-23 04:27:17.086300 11603 1097635712 Poster killed due to SIGSEGV, core file = <$SP_SYS_VARDIR/dump/core.xxxx was not generated, pid = 120597 (posting from o.sourcesid, queue name, to o.targetsid)Info 2019-04-23 04:27:17.088715 121630 1097635712 Poster launched, pid = 121630 (posting from o.sourcesid, queue name, to o.targetsid) -
Cause
Various causes:
1. Corrupted object cache for Post2. Object DDL discrepancy between failed DML and object cache ( example missing column) -
Resolution
WORKAROUND 1 -IF CORRUPTED OBJECT CACHE:
One of the reasons is, the object cache for Post on target is corrupted. To resolve the issue, you can copy the source object cache to the target with the sp_ctrl command copy cache as below:
source:sp_ctrl> copy cacheThe above will recreate the Post object cache from Capture object cachce. You can then start Post manually on target sp_ctrl:target:sp_ctrl> start post [ queue_name]In a scenario where the corrupted object cache for Post happens to be from an activation id from past and not the current activation id, the “copy cache” will not be helpful. The steps involved are more elaborate and are as follows:1 Issue "list config" to get the activation id from source side. For example, in the following, the activation id is 13:
test.cfg Active o.sourceSID
Last Modified At: 04-Dec-19 17:10 Size: 3179 Internal Name: .conf.13
2. Make a copy of the currently active config file and activate the copy. Now the "list config" will show the activation id of 14.
3. Stop Capture and make sure it is "stopped by user" and then restart Capture.
4. Issue "ls -ltr *objcacje*" from /vardir/state to get the latest Capture object cache. In our example, it would end with *sp_ocap.14*
5. Send that Capture object cache file to the target state directory by ftp or scp and do so in bin mode.
6. Issue "ls -ltr *objcacje*" to get the last Post object cache file accessed by Post for our problem Post queue named 2150. You can rename it to another name for the purpose of backing it up and then recreate it from the Capture object cache brought here in step 5.
7. Restart Post.
If the above steps are too complicated or do not help, contact Support so that the issue can be further investigated.
WORKAROUND 2 - IF OBJECT DDL DISCREPANCY BETWEEN FAILED DML & OBJECT CACHE FILE:1. Turn on post debug on both failed queuesset param SP_OPO_DEBUG_FLAG queue 0x1f0000ff2. Reviewed opo logs3. Identify information for failed DML4. Turn off post debug on both failed queuesreset param SP_OPO_DEBUG_FLAG queue5. Dump object cache for failed DML actid6. Review DDL for failed object7. Compare DDL in dumped object cache and target database object description8. Proceed with desired options:i. Discard offending DML from queue, resync discarded DMLii. Disable affected table by setting SP_OPO_DISABLE_OBJECT_NUM & bounce post, resync tableiii. Correct target table DDL to match the failed DML, and restart post loading appropriate object cache file9. Start post