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
anotherserver 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
theraster 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 <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee