On Wed, Jan 9, 2019 at 12:06 PM Michael Banck <michael.ba...@credativ.de> wrote:
> Hi, > > there was a report in #postgresql recently about a crash on Google Cloud > SQL with the somewhat misleading message "could not write to log file" > while in fact it was the xlog/wal: > > |PANIC: could not write to log file 000000010000019600000054 at offset > | 13279232, length 245760: Cannot allocate memory > |ERROR: could not write block 74666 in file "base/18031/48587": Cannot > | allocate memory > |CONTEXT: writing block 74666 of relation base/18031/48587 > |LOG: server process (PID 5160) was terminated by signal 9: Killed > > The slightly longer logfile can be found here: http://dpaste.com/2T61PS9 > > I suggest to reword that message, e.g. "could not write to transaction > log file" or "could not write to wal file". > Given the change xlog -> wal, I would suggest "could not write to wal file" as the correct option there. And +1 for rewording it. I think there are also some other messages like it that needs to be changed, and also things like (errmsg("restored log file \"%s\" from archive" could do with an update. Also, the errno (ENOMEM) is curious (and the user wrote that Google > monitoring reported memory at 16/20GB at the time of the crash), but it > could be a due to running on a cloud-fork? As you have no access to > PGDATA, it sounds difficult to diagnose after the fact. > Yeah, nobody knows what Google has done in their fork *or* how they actually measure those things, so without a repro I think that's hard.. //Magnus
