Jaime, Sorry it took so long for you to get a mantra. I think we are usually more responsive but I've personally been very busy the past few weeks. Seems Covid only added more work for me.
That said -- we are pretty open to getting pull requests from any of our code mirrors outlined below https://trac.osgeo.org/postgis/wiki/CodeMirrors Or as a Patch on our trac bug tracker. For just issue reporting, we prefer that be done in Trac. https://trac.osgeo.org/postgis If you have a pull request and didn't want to bother with trac, that's fine , just will add a bit more work for us to assure it is noted in release. Thanks, Regina > -----Original Message----- > From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On > Behalf Of Jaime Casanova > Sent: Saturday, June 6, 2020 2:20 PM > To: PostGIS Users Discussion <postgis-users@lists.osgeo.org> > Subject: Re: [postgis-users] where to report bugs? > > On Sat, 6 Jun 2020 at 11:34, Darafei "Kom?pa" Praliaskouski > <m...@komzpa.net> wrote: > > > > Hello, > > > > You followed the best practice to report it. Trac is officially a bug > > tracker. > > > > Best way to get it fixed is to stomp it into a Github pull request with > minimized version of your case in regress suite. > > Somewhere in here: > https://github.com/postgis/postgis/tree/master/raster/test/regress - press > "Edit" on a file and post a branch with that issue. > > After that, commit it as a pull request. CI (Travis) will run it and > > produce a > non-optimized backtrace. It usually helps a tiny bit more, letting you > understand what went wrong through all the "optimized out"-s. > > > > interesting, you mean in addition to add it to trac? (i have received the > mantra now) > > > Reasons why your report is hanging for now are: > > - people have lives and postgis is a hobby; > > maybe i'm just used to the response times in postgresql lists > > > - nobody really dug deep into raster codebase in last years, so you > > have a perfect opportunity to become world's best expert; > > sadly, i don't actually know to much about GIS. i'm doing this exercise by my > own because some customers uses postgis and i prefer a system that doesn't > crash in simple ways > > > - it's synthetic query by a tool designed to break stuff, meaning there's > > no > human being that wrote that query who you can empathize with to get thing > fixed. > > > > yes, you're right about the query being synthetic and sqlsmith being designed > to break things in odd ways. > > having said that, this normally results in finding spots that could result in > hard > to find errors. > this example could have bite people that have nulls in a raster column. > > > I've looked at your query and it looks like the whole report should have > been just one line: > > > > select st_union(null::raster, 4); > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > > > curious, i did try to simplify it more but when i removed the tablesample it > didn't crash so i stoped there... but probably i had already made the change > to check the null... > > in my defense it was too late for me at the time ;) > > > -- > Jaime Casanova www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > _______________________________________________ > postgis-users mailing list > postgis-users@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
