Non-writable socket some hours into migration from MariaDB to Postgres

Troubleshooting
1

I’m trying to migrate a very large MariaDB db from a Teams installation (testing dump was at version10.11.16) over to Postgres on a Debian Trixie host, pgloader version “3.6.10~devel” from the official repo.

I’ve followed the guidance here, producing a load file that is accepted no problem:

The pgload starts off well, runs for a few hours, and then fails at this same location, with the same output.

21: (LPARALLEL.KERNEL::%CALL-WITH-TASK-HANDLER #<unavailable argument>)                                                                                                                        
22: ((LAMBDA NIL :IN LPARALLEL.KERNEL::CALL-WITH-WORKER-CONTEXT))
23: (LPARALLEL.KERNEL::CALL-WITH-WORKER-CONTEXT #<FUNCTION (LAMBDA NIL :IN LPARALLEL.KERNEL::ENTER-WORKER-LOOP) {1006E28A0B}> #<FUNCTION FUNCALL> #<LPARALLEL.KERNEL:KERNEL :NAME "lparallel" :WORKER-COUNT 16 :USE-CALLER NIL :ALIVE T :SPIN-COUNT 2000 {1006D5E1D3}> #S(LPARALLEL.KERNEL::WORKER :HANDSHAKE/FROM-WORKER #S(LPARALLEL.CONS-QUEUE:CONS-QUEUE :IMPL #S(LPARALLEL.RAW-QUEUE:RAW-QUEUE :HEAD NIL :TAIL NIL) :LOCK #<SB-THREAD:MUTEX #1="Anonymous lock" free owner=0> :CVAR NIL) :HANDSHAKE/TO-WORKER #S(LPARALLEL.CONS-QUEUE:CONS-QUEUE :IMPL #S(LPARALLEL.RAW-QUEUE:RAW-QUEUE :HEAD NIL :TAIL NIL) :LOCK #<SB-THREAD:MUTEX #1# free owner=0> :CVAR #<SB-THREAD:WAITQUEUE Anonymous condition variable {1004FCB7A3}>) :EXIT-NOTIFICATION #S(LPARALLEL.CONS-QUEUE:CONS-QUEUE :IMPL #S(LPARALLEL.RAW-QUEUE:RAW-QUEUE :HEAD NIL :TAIL NIL) :LOCK #<SB-THREAD:MUTEX #1# free owner=0> :CVAR NIL) :THREAD #<SB-THREAD:THREAD tid=666931 "lparallel" RUNNING {1004FC8003}> :RUNNING-CATEGORY :DEFAULT :INDEX 15 :TASKS #S(LPARALLEL.SPIN-QUEUE:SPIN-QUEUE :HEAD (LPARALLEL.SPIN-QUEUE::DUMMY (#<FUNCTION #2=(LAMBDA NIL :IN LPARALLEL.KERNEL::MAKE-CHANNELED-TASK) {10054E2F4B}> . :DEFAULT) (#<FUNCTION #2# {10054E2F7B}> . :DEFAULT) (#<FUNCTION #2# {10054E2FAB}> . :DEFAULT) (#<FUNCTION #2# {10054E2FDB}> . :DEFAULT) (#<FUNCTION #2# {10054E300B}> . :DEFAULT) (#<FUNCTION #2# {10054E303B}> . :DEFAULT) (#<FUNCTION #2# {10054E306B}> . :DEFAULT) (#<FUNCTION #2# {10054E309B}> . :DEFAULT) (#<FUNCTION #2# {10054E30CB}> . :DEFAULT) (#<FUNCTION #2# {10054E30FB}> . :DEFAULT) (#<FUNCTION #2# {10054E312B}> . :DEFAULT) (#<FUNCTION #2# {10054E315B}> . :DEFAULT) (#<FUNCTION #2# {10054E318B}> . :DEFAULT) (#<FUNCTION #2# {10054E31BB}> . :DEFAULT) (#<FUNCTION #2# {10054E31EB}> . :DEFAULT) (#<FUNCTION #2# {10054E321B}> . :DEFAULT) (#<FUNCTION #2# {10054E324B}> . :DEFAULT) (#<FUNCTION #2# {10054E327B}> . :DEFAULT) (#<FUNCTION #2# {10054E32AB}> . :DEFAULT) (#<FUNCTION #2# {10054E32DB}> . :DEFAULT) (#<FUNCTION #2# {10054E330B}> . :DEFAULT) (#<FUNCTION #2# {10054E333B}> . :DEFAULT) (#<FUNCTION #2# {10054E336B}> . :DEFAULT) (#<FUNCTION #2# {10054E339B}> . :DEFAULT) (#<FUNCTION #2# {10054E33CB}> . :DEFAULT) (#<FUNCTION #2# {10054E33FB}> . :DEFAULT) (#<FUNCTION #2# {10054E342B}> . :DEFAULT) (#<FUNCTION #2# {10054E345B}> . :DEFAULT) (#<FUNCTION #2# {10054E348B}> . :DEFAULT) (#<FUNCTION #2# {10054E34BB}> . :DEFAULT) (#<FUNCTION #2# {10054E34EB}> . :DEFAULT) (#<FUNCTION #2# {10054E351B}> . :DEFAULT) (#<FUNCTION #2# {10054E354B}> . :DEFAULT) (#<FUNCTION #2# {10054E357B}> . :DEFAULT) (#<FUNCTION #2# {10054E35AB}> . :DEFAULT) (#<FUNCTION #2# {10054E35DB}> . :DEFAULT) (#<FUNCTION #2# {10054E360B}> . :DEFAULT) (#<FUNCTION #2# {10054E363B}> . :DEFAULT) . #3=((#<FUNCTION #2# {10054E366B}> . :DEFAULT))) :TAIL #3#)))
24: ((LAMBDA NIL :IN LPARALLEL.KERNEL::MAKE-WORKER-THREAD))
25: ((LABELS *****-THREADS::%BINDING-DEFAULT-SPECIALS-WRAPPER :IN *****-THREADS::BINDING-DEFAULT-SPECIALS))
26: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
27: ((FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN))
28: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
29: ((FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN))
30: (SB-THREAD::RUN)
31: ("foreign function: call_into_lisp_")
32: ("foreign function: funcall1")
 
 
What I am doing here?
 
Couldn't write to #<SB-SYS:FD-STREAM for "socket 127.0.0.1:54664, peer: 127.0.0.1:3306" {10053F04A3}>:

Both MariaDB and Postgres processes remain up and accessible immediately after this failure.

I’ll try doubling the work_mem and maintenance_work_mem now in case it’s a case of brief memory exhaustion but the fact it occurs in the same place doesn’t give me much hope that will help.

If any have clues I’d be grateful.

2

Thanks for the detailed logs - since direct MariaDB-to-PostgreSQL migrations aren’t currently supported, I’d recommend first moving the database to supported MySQL, then rerunning with the official mattermost/pgloader image and sharing the first error lines before the stack trace if the socket failure persists: Mattermost PostgreSQL migration guidance.