spetz commented on code in PR #3957:
URL: https://github.com/apache/iggy/pull/3957#discussion_r3999174714
##########
core/connectors/sources/postgres_source/src/lib.rs:
##########
@@ -1460,6 +1777,59 @@ fn format_offset_value(value: &str) -> String {
}
}
+fn build_tracking_condition(
+ tracking_column: &str,
+ tracking_boundary: Option<&str>,
+) -> Result<String, Error> {
+ let Some(boundary) = tracking_boundary else {
+ return Ok(String::new());
+ };
+ let quoted_tracking = quote_identifier(tracking_column)?;
+ Ok(format!(
+ " AND ({quoted_tracking} <= {} OR {quoted_tracking} IS NULL)",
+ format_offset_value(boundary)
Review Comment:
The new cleanup boundary routes its value through the pre-existing
`format_offset_value`, which leaves anything `f64::from_str` accepts unquoted.
Emitted SQL verified on this branch: `"100"` produces ` AND ("id" <= 100 OR
"id" IS NULL)`, and `"NaN"`, `"inf"`, `"-infinity"` produce ` AND ("id" <= NaN
...)`, ` AND ("id" <= inf ...)`, ` AND ("id" <= -infinity ...)`. A text
tracking column holding digits yields `text <= integer`, for which PostgreSQL
has no operator. A text tracking column holding `NaN` or `inf` yields a bare
token PostgreSQL resolves as a column reference, giving `column "nan" does not
exist`. Either failure breaks every delete or mark, and since `ProcessRows`
failures are uncapped at line 860 the source then wedges at zero throughput
reporting `Running`.
`given_exact_numeric_boundary_should_preserve_text_and_include_null_rows` at
line 2189 locks the unquoted form in, so this is a design choice rather than an
oversight. PR #4153 changes `format_offset_value` to alway
s quote and let PostgreSQL infer the literal type from the compared column,
which resolves both cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
