Re: Misleading panic message in backend/access/transam/xlog.c

On Wed, Jan 9, 2019 at 12:06 PM Michael Banck <michael(dot)banck(at)credativ(dot)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