The server was destroyed.
But did copy the pg_data folder and restored it on the test server.
It failed with similar error. Will that do.
I do have some very high (DEBUG5) level logs in my console along with strace (postgresql start) logs.
Not sure if this is ok to paste in the mail (it will not be readable)
On 6/28/18, 10:16 PM, "Andres Freund" <andres@xxxxxxxxxxx> wrote:
Hi,
On 2018-06-28 10:43:16 -0600, Scott Ribe wrote:
> > On Jun 28, 2018, at 10:36 AM, Andres Freund <andres@xxxxxxxxxxx> wrote:
> >
> > How are you making the inference that that's the problem? It could very
> > well be a postgres bug or somebody having used pg_resetxlog or.. ?
>
> There could always be a postgres bug, however misconfigured cache
> layers are a very common cause of this kind of symptom, and postgres
> bugs very rare.
Sure, but it's also easy to not find postgres bugs if you don't
investigate. If the error comes from parsing WAL - which is likely but
not guaranteed from the log output - then it's unlikely the error is
caused by on-disk corruption. The WAL is protected by a CRC checksum,
and if it fails, you don't get to the memory allocation bit.
> I don't believe pg_resetxlog would cause this particular
> problem. Failure to recovery yes, but not illegal memory operation.
It can. Not as a result of reading WAL itself, but as a result of the
resulting corruption. That's why I asked for debugging output.
- Andres
