Skip to content

Fix reading attributes of nodes from the middle - #2501

Merged
joto merged 2 commits into
osm2pgsql-dev:masterfrom
leijurv:fix-middle-attributes
Sep 26, 2026
Merged

joto merged 2 commits into
osm2pgsql-dev:masterfrom
leijurv:fix-middle-attributes

Conversation

@leijurv

@leijurv leijurv commented Sep 24, 2026

Copy link
Copy Markdown
Contributor

Fix an issue where public-transport.lua currently fails when run with --slim -x. Issue present since 8d1a55e

The cause is that set_attributes_on_builder would get its attribute columns from offset + 2, which is correct for ways and relations, but incorrect for nodes. A node that was read back from the middle now would get misaligned columns: it would get a changeset where it expected a timestamp, a uid where it expected a version, and a username where it expected a changeset, that last one having caused the actual crash with illegal changeset: 'marcoh'.

Command to reproduce: osm2pgsql -d ptx -O flex -S public-transport.lua --slim -x ../tests/data/liechtenstein-2013-08-03.osm.pbf

Logs currently on master (click to expand)
2026-09-24 14:50:52  osm2pgsql version 2.3.0 (2.3.0-16-gf720d32d)
2026-09-24 14:50:52  Database version: 18.6 (Debian 18.6-1.pgdg13+2)
2026-09-24 14:50:52  PostGIS version: 3.6
2026-09-24 14:50:52  Initializing properties table '"public"."osm2pgsql_properties"'.
2026-09-24 14:50:52  Storing properties to table '"public"."osm2pgsql_properties"'.
2026-09-24 14:50:52  Writing 226 entries to table 'planet_osm_users'...
2026-09-24 14:50:52  Reading input files done in 0s.
2026-09-24 14:50:52    Processed 65733 nodes in 0s - 66k/s
2026-09-24 14:50:52    Processed 7121 ways in 0s - 7k/s
2026-09-24 14:50:52    Processed 113 relations in 0s - 113/s
2026-09-24 14:50:52  Reprocess marked nodes/ways (stage 2)...
2026-09-24 14:50:52  Creating id index on table 'lines'...
2026-09-24 14:50:52  Creating id indexes took 0s
2026-09-24 14:50:52  There are 9 nodes to reprocess...
2026-09-24 14:50:52  ERROR: illegal changeset: 'marcoh'
Logs with this fix (click to expand)
2026-09-24 14:50:53  osm2pgsql version 2.3.0 (2.3.0-16-gf720d32d-changed)
2026-09-24 14:50:53  Database version: 18.6 (Debian 18.6-1.pgdg13+2)
2026-09-24 14:50:53  PostGIS version: 3.6
2026-09-24 14:50:53  Initializing properties table '"public"."osm2pgsql_properties"'.
2026-09-24 14:50:53  Storing properties to table '"public"."osm2pgsql_properties"'.
2026-09-24 14:50:53  Writing 226 entries to table 'planet_osm_users'...
2026-09-24 14:50:53  Reading input files done in 0s.
2026-09-24 14:50:53    Processed 65733 nodes in 0s - 66k/s
2026-09-24 14:50:53    Processed 7121 ways in 0s - 7k/s
2026-09-24 14:50:53    Processed 113 relations in 0s - 113/s
2026-09-24 14:50:53  Reprocess marked nodes/ways (stage 2)...
2026-09-24 14:50:53  Creating id index on table 'lines'...
2026-09-24 14:50:53  Creating id indexes took 0s
2026-09-24 14:50:53  There are 9 nodes to reprocess...
2026-09-24 14:50:53  There are 287 ways to reprocess...
2026-09-24 14:50:53  Building index on middle ways table
2026-09-24 14:50:53  Building indexes on middle rels table
2026-09-24 14:50:53  Done postprocessing on table 'planet_osm_nodes' in 0s
2026-09-24 14:50:53  Clustering table 'lines' by geometry...
2026-09-24 14:50:53  Clustering table 'stop_areas' by geometry...
2026-09-24 14:50:53  No indexes to create on table 'routes'.
2026-09-24 14:50:53  Creating id index on table 'routes'...
2026-09-24 14:50:53  Clustering table 'stops' by geometry...
2026-09-24 14:50:53  Analyzing table 'routes'...
2026-09-24 14:50:53  Creating index on table 'stop_areas' ("geom")...
2026-09-24 14:50:53  Creating index on table 'stops' ("geom")...
2026-09-24 14:50:53  Creating id index on table 'stop_areas'...
2026-09-24 14:50:53  Creating id index on table 'stops'...
2026-09-24 14:50:53  Analyzing table 'stop_areas'...
2026-09-24 14:50:53  Analyzing table 'stops'...
2026-09-24 14:50:53  Creating index on table 'lines' ("geom")...
2026-09-24 14:50:53  Creating id index on table 'lines'...
2026-09-24 14:50:53  Analyzing table 'lines'...
2026-09-24 14:50:53  Done postprocessing on table 'planet_osm_ways' in 0s
2026-09-24 14:50:53  Done postprocessing on table 'planet_osm_rels' in 0s
2026-09-24 14:50:53  All postprocessing on table 'stops' done in 0s.
2026-09-24 14:50:53  All postprocessing on table 'lines' done in 0s.
2026-09-24 14:50:53  All postprocessing on table 'routes' done in 0s.
2026-09-24 14:50:53  All postprocessing on table 'stop_areas' done in 0s.
2026-09-24 14:50:53  Storing properties to table '"public"."osm2pgsql_properties"'.
2026-09-24 14:50:53  osm2pgsql took 0s overall.

Comment thread tests/test-middle.cpp Outdated
check(mid);
}

// From now on use append mode to not destroy the data we just added.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a specific reason why you are running again here in append mode. It seems this doesn't have anything to do with the test we are doing here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joto
joto self-requested a review September 26, 2026 09:30
@joto
joto merged commit 2cc87ef into osm2pgsql-dev:master Sep 26, 2026
24 checks passed
@joto

joto commented Sep 26, 2026

Copy link
Copy Markdown
Collaborator

Thanks!

joto added a commit that referenced this pull request Oct 25, 2026
Fixes #2286 

This PR switches the Postgres COPY for the middle tables and most flex
tables from the textual format to the binary format. This is a moderate
win in decreasing CPU time that is otherwise spent on
int-to-text-to-int, float-to-text-to-float, WKB hex, etc.

Details:
- Each `db_target_descr_t` knows the binary versions of its column
types, if present `db_copy_mgr_t` will seamlessly switch to binary
format for the same calls (`add_column`, `new_array`, etc)
- Binary mode checks each field's type from the list, asserting that it
matches
- Middle tables will always use binary mode. In particular, `int8[]` is
supported, to make this possible.
- Flex tables use binary mode if they only use the following types:
text, boolean, int2/4/8, real, double precision, hstore, json, jsonb,
direction, id columns, and all geometry types. It will fall back to text
mode if user-defined SQL types are present, or if there is
timestamp/timestamptz directly from Lua as an arbitrary string. While I
could have supported that last possibility, there is a better
alternative (#2502) that doesn't require complicated timestamp parsing
code.
- Pgsql output and gen are unchanged, still text.
- #2500 is supported

Changes to behavior:
- No change for integers, doubles, text, json, hstore, arrays,
timestamps, or WKB from OSM data.
- If the Lua gives a double which is stored in PG as a `real`, currently
text mode implicitly does fp64 -> text -> fp32. This causes rounding to
happen twice. Binary mode will now round fp64 -> fp32 directly. Of
course, one could reimplement the double rounding behavior, but I don't
think this is good behavior to preserve. The effect is at most 1 ULP of
difference, and it only happens when a fp64 landed exactly halfway
between two fp32 values, which is extremely unlikely. A potential place
where this could theoretically arise is in `way_area` - but in practice,
there are none, in the full current planet, that have any difference
here, and there probably never will be, as less than 1 in a billion
doubles are like this. Out of range values like inf remain an error as
in text mode.

Testing:
- Lots of tests in `test-db-copy-mgr.cpp`
- All ctest and BDD pass
- Tested all examples in flex-config, and also osm carto. Imported with
`--slim -x` and then updated with an .osc. (this is what exposed #2501).
All table contents identical to master.

Performance:
- Ryzen 9 3900X, Samsung 970 EVO Plus NVMe, Postgres 18.6, PostGIS 3.6.4
- OSM Carto flex style. Nodes cached in RAM (no flat nodes.bin).
- Cold restart every time
- Alternating runs between this branch and master, taking the median of
seven.

|Extract (from geofabrik)|Flags|Wall clock time|Postgres CPU, import
phase|Postgres CPU, total|osm2pgsql CPU|
|---|---|---|---|---|---|
| Delaware | `--slim` | 12.74 -> 12.36 s (−3.0%) | 7.45 -> 6.44 s
(−13.6%) | 13.03 -> 12.03 s (−7.7%) | 6.92 -> 6.59 s (−4.8%) |
| Delaware | `--slim --drop` | 12.36 -> 12.02 s (−2.8%) | 6.64 -> 5.69 s
(−14.3%) | 9.00 -> 8.05 s (−10.6%) | 6.89 -> 6.57 s (−4.6%) |
| New Jersey | `--slim` | 83.81 -> 80.37 s (−4.1%) | 47.66 -> 41.17 s
(−13.6%) | 86.74 -> 80.13 s (−7.6%) | 48.11 -> 45.73 s (−4.9%) |

So as we can see Postgres spends about 14% less CPU to ingest. The
overall win to wall clock time is currently not so much because we are
bottlenecked by the single threaded Lua processing time. The benefit
from this PR is larger when combined with upcoming PRs... (teaser post
credit scene 😺) (EDIT: this was teasing #2504)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants