Strange runtime error…

[sommerluk]

Strange runtime error…

Trace
    at ProjectServer.raise (/home/sommerluk/Dokumente/OSM/kosmtik/src/back/ProjectServer.js:257:13)
    at /home/sommerluk/Dokumente/OSM/kosmtik/src/back/ProjectServer.js:71:30
    at /home/sommerluk/Dokumente/OSM/kosmtik/node_modules/mapnik-pool/node_modules/generic-pool/lib/generic-pool.js:283:11
    at loaded (/home/sommerluk/Dokumente/OSM/kosmtik/node_modules/mapnik-pool/index.js:23:37)
Postgis Plugin: FEHLER:  Operator existiert nicht: hstore -> boolean
LINE 8: ...T NULL) OR ("addr:housename" IS NOT NULL) OR (tags->'addr:un...
                                                             ^
HINT:  Kein Operator stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.
in executeQuery Full sql was: 'SELECT * FROM (SELECT
    way,
    "addr:housenumber" AS addr_housenumber,
    "addr:housename" AS addr_housename,
    tags->'addr:unit' AS addr_unit,
    way_area/NULLIF(0::real*0::real,0) AS way_pixels
  FROM planet_osm_polygon
  WHERE (("addr:housenumber" IS NOT NULL) OR ("addr:housename" IS NOT NULL) OR (tags->'addr:unit' IS NOT NULL))
    AND building IS NOT NULL
UNION ALL
SELECT
    way,
    "addr:housenumber" AS addr_housenumber,
    "addr:housename" AS addr_housename,
    tags->'addr:unit' AS addr_unit,
    NULL AS way_pixels
  FROM planet_osm_point
  WHERE ("addr:housenumber" IS NOT NULL) OR ("addr:housename" IS NOT NULL) OR (tags->'addr:unit' IS NOT NULL)
  ORDER BY way_pixels DESC NULLS LAST
) AS addresses LIMIT 0'
  encountered during parsing of layer 'addresses' in Layer
[httpserver] /openstreetmap-carto-with-data/tile/17/82549/56277.png?t=1507477774906 500
[httpserver] /favicon.ico 200
[httpserver] /openstreetmap-carto-with-data/poll/ 200

I get this with current openstreetmap-carto master since last week in my local setup (and with every other, even older branch also). Removing the two occurences of addr:unit works around. However, the addr:unit part has not been changed since months, so that cannot be the problem. Seems to be rather a local problem. But I’m not aware of any change that I’ve made in my local setup. Doing a fresh re-install of Kosmtik did not help either. Re-installing the PostGre packages (openSUSE) didn’t help either.

Any ideas?

[kocio-pl]

Nope. I tested #2494 before merging with current database and it worked.

[sommerluk]

Indeed this cannot be the result of a code change. The “unpaved” branch that I’m working with I haven’t changed since weeks. I’m sure it worked before, now it doesn’t anymore. So I think this has to do something with the setup, but I do not understand what…

[sommerluk]

#2494

I missed this one.

[kocio-pl]

What do you mean? If it resolves your problem, just close the issue, otherwise please provide more details if possible.

[sommerluk]

In the original description, I said

the addr:unit part has not been changed since months, so that cannot be the problem

This statement was wrong. I missed the merged #2494 while searching for the last modification in the house-number/address query.

So now I think that this issue is indeed triggered by #2494 The question is: Why does it work fine on some setups but triggers a bug on others?

I have

• PostGre 9.4.9
• PostGIS 2.3.3
• osm2pgsql 0.92.1
• Kosmtik 0.0.16
• carto 0.18.2

[matthijsmelissen]

Apparently your postgres instance thinks that 'addr:unit' is a boolean? @pnorman any idea?

[matthijsmelissen]

Weird, so apparently the operator precedence of -> and IN is not well-defined, or at least differs between versions.

[matthijsmelissen]

The change in behaviour from 9.5 is documented in the PostgreSQL documentation:

Adjust operator precedence to match the SQL standard (Tom Lane)

The precedence of <=, >= and <> has been reduced to match that of <, > and =. The precedence of IS tests (e.g., x IS NULL) has been reduced to be just below these six comparison operators.