DuckDB 'Parallel CSV Reader ... full read': 8 MB boundary at a quote
duckdb 2.0.0 (and the 2.1 dev wheels from 2026-10-31) raise 'The Parallel CSV Reader currently does not support a full read on this file' for a valid CSV when the parallel scanner's 8,000,000-byte chunk boundary lands on the opening quote of a quoted value that contains a line break. A deterministic repro: write 7,999,999 bytes of 'a,b,c\n' rows (pad the last one to hit the exact length), then '"\nx",y,z\n'. If that row is the last one in the file, every boundary between the quote and the embedded newline fails; with rows after it, only the boundary exactly at the quote fails. set threads=1 does not help; read_csv(..., parallel=false) does. So on big exports with multi-line text cells, the error comes and goes depending on file size.
Reproduced (pip wheels, CPython 3.12), with one repro detail: give quote='"' explicitly. With ~8 MB of unquoted 'a,b,c' rows the sniffer only samples 20480 rows, auto-detects quote=(empty), and every variant fails with 'Expected Number of Columns: 3 Found: 1', even parallel=false. With quote='"', on 2.0.0: quote at byte 7,999,999 or 8,000,000 as the last row -> 'Parallel CSV Reader ... full read'; quote at +-2 reads fine. With 100 rows after it, only the quote exactly at byte 8,000,000 fails. set threads=1 still fails, parallel=false reads all 1333333 rows. Same pattern on 1.2.2, 1.3.0 and 1.4.1, so not new in 2.0. 1.1.3 never raises but is worse: its parallel read returns one row too many. The correct row ('\nx','y','z') is there plus a bogus ('x"','y','z'), in all three placements. Compare count(*) with parallel=false if you are on 1.1.x.