On Fri, Mar 15, 2019 at 6:09 AM Julien Rouhaud <rjuju123@gmail.com> 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