On Tue, Nov 17, 2020 at 02:44:47PM -0500, Bruce Momjian wrote:
> On Tue, Nov 17, 2020 at 11:59:10AM -0500, Jeremy Wilson wrote:
> > pg_restore: WARNING: terminating connection because of crash of another
> > server process
> > DETAIL: The postmaster has commanded this server process to roll back the
> > current transaction and exit, because another server process exited
> > abnormally and possibly corrupted shared memory.
> > HINT: In a moment you should be able to reconnect to the database and
> > repeat your command.
> > pg_restore: creating COMMENT "public.FUNCTION "st_isempty"("rast"
> > "public"."raster")"
> > pg_restore: while PROCESSING TOC:
> > pg_restore: from TOC entry 5338; 0 0 COMMENT FUNCTION "st_isempty"("rast"
> > "public"."raster") postgres
> > pg_restore: error: could not execute query: server closed the connection
> > unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > Command was: COMMENT ON FUNCTION "public"."st_isempty"("rast"
> > "public"."raster") IS 'args: rast - Returns true if the raster is empty
> > (width = 0 and height = 0). Otherwise, returns false.’;
>
> My guess is that this is a crash in the PostGIS shared library. I would
> ask the PostGIS team if they know of any crash cases, and if not, I
> think you need to do a pg_dump of the database and test-load it into a
> new database to see what query makes it fail, and then load debug
> symbols and do a backtrace of the stack at the point of the crash.
> Yeah, not fun.
Actually pg_dump --schema-only is what you want to dump and load into a
separate databsae. No need to dump the data.
--
Bruce Momjian <[email protected]> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
