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

Hi,

On 2019-01-09 12:06:39 +0100, Michael Banck wrote:
> 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".

I'm quite unenthused about that. If anything, I'd remove detail and use
the standard error message about not being able to write to a file, and
include the full path.

> 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.

Yes, that sounds quite likely. This pretty much is a write() which isn't
documented to return ENOMEM commonly, so I assume Google's doing
something odd.

Greetings,

Andres Freund