> On Nov 17, 2020, at 11:44 AM, Bruce Momjian <bruce@xxxxxxxxxx> 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.
These kinds of problems have been almost always due to multiple versions of dependencies installed simultaneously. So packaging fun. You'll get some version of postgis compiled against one train of dependencies and another against another train, and for upgrade both trains will end up installed simultaneously, and things will break.
P
>
> --
> Bruce Momjian <bruce@xxxxxxxxxx> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>
>
>
