On Wed, 14 Jan 2026 at 23:52, Hannu Krosing <[email protected]> wrote: > > On Tue, Jan 13, 2026 at 3:27 AM David Rowley <[email protected]> wrote: > > On testing Citus's columnar AM, I get: > > postgres=# select * from t where ctid between '(0,1)' and '(10,0)'; > > ERROR: UPDATE and CTID scans not supported for ColumnarScan > > Should we just silently not chunk tables that have some storage > architecture that does not have tids, or should pg_dump just error out > in thiscase ?
I think you should just document that it only applies to heap tables. I don't think erroring out is useful to anyone, especially if the error only arrives after pg_dump has been running for several hours or even days. > > 4. I think using "int" here is a future complaint waiting to happen. > > > > + if (!option_parse_int(optarg, "--huge-table-chunk-pages", 1, INT32_MAX, > > + &dopt.huge_table_chunk_pages)) > > > > I bet we'll eventually see a complaint that someone can't make the > > segment size larger than 16TB. I think option_parse_uint32() might be > > called for. > > There can be no more than 2 * INT2_MAX pages anyway. > I thought half of the max possible size should be enough. > Do you really think that somebody would want that ? IMO, if the option can't represent the full range of BlockNumber, then that's a bug. I see pg_resetwal has recently invented strtouint32_strict for this. It might be a good idea to refactor that and put it into option_utils.c rather than having each client app have to invent their own method. David
