I tried the workaround that was mentioned on the stack overflow thread here https://stackoverflow.com/q/76192816/322049 It mentions that disabling JIT could fix the issue
show jit; --equals to ON alter database top set jit=off; -- reconnect to db show jit; --equals to off With jit == off the query runs without issues, still i doesn't seem the appropiate thing to do, and on the replica system there's no need to disable the JIT. Shall I open a bug? Missatge de Joan <aseq...@gmail.com> del dia dt., 4 de juny 2024 a les 18:00: > I have recently upgraded the postgis and pgrouting extensions on a server > via the pgdg repository from 3.3.1 to 3.4.2, this are my current versions > (the exact same versions are installed on another server with and older > copy of the database without the same synthoms) > > Name | Version | Schema > ------------------+---------+------------- > pgrouting | 3.6.2 | public > plpgsql | 1.0 | pg_catalog > postgis | 3.4.2 | public > postgis_raster | 3.4.2 | public > postgis_topology | 3.4.2 | topology > tds_fdw | 2.0.3 | public > > When I call this query > > select * > FROM topo.arcs t, > topo.nodes n > where > t.geom is not null > and n.geom is not null > and ST_DWithin(ST_StartPoint(t.geom), n.geom, 0.01) > > On the sql program (even local console): > >> SQL Error [08006]: An I/O error occurred while sending to the backend. > > On the postgres logs I see this line though: > >> error: Not an int attribute (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.0') > > > > On a stackoverflow I found a mention that this could be related to the JIT > compilation > and suggested disabling it, but I'd like to investigate more before doing > so > > Any pointers will be appreciated, > > Thanks, > > Joan > >
