From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | Rui DeSousa <rui(at)crazybean(dot)net>, Vijaykumar Jain <vjain(at)opentable(dot)com>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [External] Re: standby replication server throws invalid memory alloc request size , does not start up |
Date: | 2018-06-28 16:46:33 |
Message-ID: | 20180628164633.uyhnlid7odwopkmv@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi,
On 2018-06-28 10:43:16 -0600, Scott Ribe wrote:
> > On Jun 28, 2018, at 10:36 AM, Andres Freund <andres(at)anarazel(dot)de> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vijaykumar Jain | 2018-06-28 17:00:23 | Re: [External] Re: standby replication server throws invalid memory alloc request size , does not start up |
Previous Message | Scott Ribe | 2018-06-28 16:43:16 | Re: [External] Re: standby replication server throws invalid memory alloc request size , does not start up |