On Fri, Mar 15, 2019 at 6:09 AM Julien Rouhaud <rjuju123@xxxxxxxxx> wrote: > > > > https://trac.osgeo.org/postgis/ticket/4129 > I also tried to reproduce on latest postgis 2.4 / pg11 with anything > even slightly related to what could call GetLatestSnapshot() with > force_parallel_mode enabled and parallel_leader_participation disabled > (also postgis installcheck), and I couldn't hit this problem (while > I'm sure that the underlying query was run). I start to think that > this may be due to a third-party module loaded that could call > GetLatestSnapshot(), otherwise I have no explanation. I don't know much about PostGIS but this does seem very strange. Comment #7 in the Trac bug says that the error occurs only intermittently. Hmm, so what could reach GetLatestSnapshot() only occasionally...? Generally that is used for things that are doing RI checks and other special things involving write queries, but these aren't write queries, or shouldn't be. It should be perfectly OK for SPI stuff to happen inside PARALLEL SAFE functions, as long as they only do read-only queries; I hope that any SRID lookup-type activity hiding in these functions is just doing read-only work (for example we've found a few core function that we had to mark as UNSAFE after we realised that they could run user-supplied queries that could do anything). A fast way to find out would be to get one of these people who can reproduce the problem to recompile PostgreSQL with that error changed to a PANIC, and examine the resulting smoldering core. (Someone had a proposal to make PostgreSQL errors optionally dump the function call stack with backtrace(3) even in regular production builds, which would make this kind of investigations go faster, I wonder what happened to that.) -- Thomas Munro https://enterprisedb.com
