StrikeW

I found same [error logs](https://grafana.test.risingwave-cloud.xyz/explore?panes=%7B%22c82%22:%7B%22datasource%22:%22PE59595AED52CF917%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Bcomponent%3D%5C%22compute%5C%22,%20namespace%3D%5C%22longcmkf-20240401-034537%5C%22%7D%20%7C~%20%60%28Cannot%20seek%20to%20the%20last%20known%20offset%7Cadvance%29%60%22,%22queryType%22:%22range%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22PE59595AED52CF917%22%7D,%22editorMode%22:%22builder%22%7D%5D,%22range%22:%7B%22from%22:%221711944000000%22,%22to%22:%221711947599000%22%7D%7D%7D&schemaVersion=1&orgId=1) as in the #15141. We are working a fix patch to try to fix the issue, tracked in #15464

Hi @xuefengze, please rerun the test with `RW_VERSION=cdc-commit-offset`, which is the image of https://github.com/risingwavelabs/risingwave/pull/16058

I run the chaos test with the image built by https://github.com/risingwavelabs/risingwave/pull/16058, the `Cannot seek to the last known offset` [WARN logs](https://grafana.test.risingwave-cloud.xyz/explore?panes=%7B%22Iee%22:%7B%22datasource%22:%22PE59595AED52CF917%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Bcomponent%3D%5C%22compute%5C%22,%20namespace%3D%5C%22longcmkf-20240410-030746%5C%22%7D%20%7C~%20%60%28cannot%20seek%7Cadvance%29%60%22,%22queryType%22:%22range%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22PE59595AED52CF917%22%7D,%22editorMode%22:%22builder%22%7D%5D,%22range%22:%7B%22from%22:%221712718000000%22,%22to%22:%221712721599000%22%7D%7D%7D&schemaVersion=1&orgId=1) are gone, which means the persistent source offset are...

I also run against the nightly image ([750](https://buildkite.com/risingwave-test/chaos-mesh/builds/750)), the symptom is same: RW rows is more than upstream pg.

> During a previous refactor to source parser, I found a possible cause of cdc offset rewind, which according to @StrikeW is possibly a reason of this issue. The bug...

I run the chaos mesh test against the PR, but it fails in q3. https://buildkite.com/risingwave-test/chaos-mesh/builds/816#018f5610-37ba-450c-8c59-067fa74e648e But the [nightly](https://buildkite.com/risingwave-test/chaos-mesh/builds/815#018f560e-ac3b-4222-b4b3-614496357288) image can pass the test. ``` BENCH_TESTBED=medium-arm-all-affinity CH_BENCHMARK_QUERY=q1,q2,q3,q4 RW_VERSION=nightly-20240507 BENCHMARK_TYPE=tpc TPC_TARGET=postgres duration=10m...

> We do have an `NaN` in decimal > > https://github.com/risingwavelabs/risingwave/blob/ae7d7ba426818d43209be545ad72f979ce3dacc0/src/common/src/types/decimal.rs#L44 Yeah, I know that. The problem is that the `rust_decimal` crate cannot represent `NaN`. A upstream `NaN` will be...

cc @yezizp2012

So your point is that the MySQL `bit` data type should be only mapped to `Vec` in Rust, am I get you right? > BTW, why are you using bit(1)...

I am trying to reproduce the issue, it seems AWS RDS would generate WALs behind the scene: > For users on AWS RDS with PostgreSQL, a situation similar to the...