Gunnar "Nick" Bluth

Confirmed that catchsegv doesn't yield anything... Will try to get a coredump.

Do these help? I got this error from GDB for 5 of the files: `1261 common/memContext.c: No such file or directory.`

Hmm, I can't attach the tarball apparently. So here we go. Judging by the size of the coredumps, we've had 4 different crash situations, in increasing order (1x,1x,5x,10x): ``` [New...

I've set this up on our most affected server. And now we wait ;-)

Ok, so we caught some signal 11 and a signal 6. Note that I had to redact a few more informations ("redacted" w/o ""). * Signal 6 ** DB Server...

As mentioned, the local logs have *nothing* in them, e.g.: ``` 2024-02-22 20:49:20.667 P00 DEBUG: storage/storage::storageNewWrite: => {type: remote, name: /repo/archive/redacted/13-1/000000110001DF1E/000000110001DF1E000000AD-56b04711203231e816af474604c1a7e943a3691f.lz4, modeFile: 0640, modePath: 0750, createPath: true, syncFile: true, syncPath:...

D'uh! What I didn't realize was that that was actually the subprocess we're looking for...! Someone else had extracted the logs already, so I just copied them from the ticket...

No idea why I can't attach files... sorry! ``` -------------------PROCESS START------------------- 2024-02-22 20:49:19.725 P00 INFO: archive-push:local command begin 2.49: --archive-async --exec-id=1701722-03e79a03 --io-timeout=240 --log-level-console=off --log-level-file=debug --log-level-stderr=error --log-subprocess --pg1-path=/var/lib/postgresql/13/main --process=3 --remote-type=repo --repo1-host=redacted...

@dwsteele , do these shed some light on the issue?

#2108 certainly looks like something that will have *some* influence on this, yeah ;-) I guess we'll wait until we roll out a release that includes it until further investigation...