feat(fs): add OSS file system

[mrdrivingduck]

Purpose

This PR adds a native, read-only OSS filesystem backed by Alibaba Cloud OSS SDK V2.

Motivation

Static linking and distribution

Some integration scenarios require Paimon-cpp to be linked statically into another library, such as a DuckDB extension. JindoSDK is delivered as a separate dynamic library, which makes this integration and distribution model less flexible.

Shutdown reliability in PostgreSQL processes

While integrating PostgreSQL with DuckDB, we observed an intermittent shutdown hang along the PostgreSQL → DuckDB → duckdb-paimon → paimon-cpp path when JindoSDK was loaded through the Paimon filesystem. The captured shutdown stack was:

PostgreSQL backend process

proc_exit()
  → exit()
    → C++ atexit/static destructor
      → bvar::PassiveStatus::~PassiveStatus()
        → bvar::detail::Sampler::destroy()
          → pthread_mutex_lock()   ← waits indefinitely

The process also had a bvar_sampler thread running. This points to a fork/exit lifecycle issue in JindoSDK's embedded bRPC/bvar dependencies. Since JindoSDK is closed source and brings a relatively large dependency set, it is difficult to investigate or address from Paimon-cpp.

An open-source OSS filesystem

Given that OSS SDK V2 is open source, adding an OSS implementation to Paimon-cpp would provide an open and self-contained option for OSS access. The existing object-store abstraction introduced for S3 keeps this addition small and avoids duplicated filesystem logic.

Benchmark

The benchmark directly reads a 133 MiB Parquet data file belonging to a Paimon table in a real OSS environment. Both filesystems were built in a clean Release build, and each workload was run six times. Values are medians.

Workload	OSS Median	Jindo Median
Open(path)	10.63 ms (-8.3%)	11.59 ms
Open(known status)	0.73 ms (-94.9%)	14.25 ms
1 MiB range read	47.37 ms (-27.3%)	65.13 ms
Single 8 MiB sequential read	96.83 ms (-20.4%)	121.70 ms

Open(known status) reopens a file with previously obtained metadata. It avoids an extra metadata request through the status propagation introduced in #189. The range and sequential workloads each issue a single read request.

[mrdrivingduck]

I identified an OSS SDK v2 issue where a retried request can retain a stale Authorization header after its timestamp is regenerated, causing SignatureDoesNotMatch.

This PR temporarily applies a small build-time patch to overwrite the header on retry. The issue has been reported to the OSS SDK maintainers, and they will address it upstream soon.

[mrdrivingduck]

Benchmark

The benchmark directly reads a 133 MiB Parquet data file belonging to a Paimon table in a real OSS environment. Both filesystems were built in a clean Release build, and each workload was run six times. Values are medians.

Open(known status) reopens a file with previously obtained metadata. It avoids an extra metadata request through the status propagation introduced in #189. The range and sequential workloads each issue a single read request.

Oh, here is a Paimon semantic-level benchmark supplement to the pure filesystem benchmark above. FYI.

• regular_wide_rg_64k: regular append-only wide table with 64K-row Parquet row groups; used for first-batch, full, projected, and no-prebuffer scans.
• regular_wide_rg_1k: the same style of table with 1K-row groups; used for the selective predicate scan.
• regular_wide_small_files: regular table split into small data files.
• regular_partitioned: partitioned regular table; used for partition and prefetch scans.

Scenario	OSS FS	Jindo FS	OSS/Jindo
First batch	121 ms	114 ms	+6.1%
Full scan	232.7 ms	257.8 ms	-9.7%
Projected scan	123.3 ms	113.8 ms	+8.4%
Predicate scan	25 ms	24 ms	+4.2%
Small-files scan	255.7 ms	239.7 ms	+6.7%
Partition scan	65.3 ms	64.4 ms	+1.4%
Prefetch scan	765 ms	855 ms	-10.5%
Scan without Parquet prebuffer	489 ms	485 ms	+0.8%

Overall, OSS FS and Jindo FS show broadly comparable performance under Paimon scan semantics. The observed differences are generally within a single-digit range and do not indicate a consistent performance disadvantage, but much more like noise.

[zjw1111]

Thanks for the update — the previous round of comments is addressed well: the ASF headers, the int32_t / 1000 fixes, the dedicated Executor instead of the global singleton, the option-constant unification, the PAIMON_COMMON_HTTP_CLIENT_TEST_SRCS gate, and the injected HttpTransport tests are all in good shape.

Two functional issues came up on a closer read, plus a few small nits. Details inline:

• ParseTimeMillis cannot parse the timestamp format ListObjectsV2 returns, so every listed entry ends up with modification time 0 (this breaks orphan file cleanup on OSS). Same root cause exists in the S3 implementation, so a shared helper would be nice.
• InferRegion still infers a non-existent region for oss-accelerate-overseas.aliyuncs.com.

[mrdrivingduck]

While testing with OSS file system, I found an issue of executor pool. Extract it for seperated PR and I think it should be addressed first: #233.

[lxy-9602]

+1

[mrdrivingduck]

I identified an OSS SDK v2 issue where a retried request can retain a stale Authorization header after its timestamp is regenerated, causing SignatureDoesNotMatch.

This PR temporarily applies a small build-time patch to overwrite the header on retry. The issue has been reported to the OSS SDK maintainers, and they will address it upstream soon.

Fixed in https://github.com/aliyun/alibabacloud-oss-cpp-sdk-v2/releases/tag/0.1.2, so the initial patch has been removed from this commit.