Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)
Дата
Msg-id CAHyXU0z3K5VSdT2MKprsArZQRk7xTBDOM-g+GVummPTtGgcFNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
On Tue, Aug 27, 2019 at 5:52 PM Merlin Moncure <mmoncure@gmail.com> wrote:
>
> On Mon, Aug 26, 2019 at 12:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Justin Pryzby <pryzby@telsasoft.com> writes:
> > > On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote:
> > >> However ... there is some pretty interesting info at
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1338673
> > >> suggesting that compiling with a late-model gcc against older RHEL6
> > >> headers could result in bad code.  I wonder whether the reporters'
> > >> servers were built using such a configuration.  (Although the linkage,
> > >> if any, to this report still wouldn't be very clear.)
> >
> > > I can tell it was compiled using
> > > version | PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23),
64-bit
> >
> > Ah, that appears to be the default compiler for RHEL6, so that theory
> > is out the window.  It's still interesting that we're only seeing this
> > reported from RHEL6 ... maybe there's something specific to the code
> > that this gcc version generates?
>
> FWIW, I've got the same compiler (which is natural, we are likely
> using the same packaging):
> PostgreSQL 9.6.12 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313
> (Red Hat 4.4.7-23), 64-bit

I'm looking for more common threads here.   One interesting fact about
this server is that we just realized (!) that cron was attempting to
email huge log files and failing due to misconfigured email.  The mail
queue was building into the gigabytes so that on half hour cadence the
server was running out of memory until the mail process crashed.
Postgres ran just fine through this process (which is pretty cool).
So, question: were there any memory issues on the other server on or
around the crash?

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Fetching timeline during recovery
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch anddiscussion)