Horton

Re: dsa_allocate() faliure

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Sergei Kornilov <sk@zsrv.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Jakub Glapa <jakub.glapa@gmail.com>, Fabio Isabettini <fisabettini@voipfuture.com>, Arne Roland <a.roland@index.de>, Sand Stone <sand.m.stone@gmail.com>, Rick Otten <rottenwindfish@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-10T16:50:07Z
Lists: pgsql-hackers, pgsql-performance 
On Sun, Feb 10, 2019 at 07:11:22PM +0300, Sergei Kornilov wrote:
> > I ran overnight with this patch, but all parallel processes ended up stuck in
> > the style of bug#15585. So that's either not the root cause, or there's a 2nd
> > issue.
> 
> Maybe i missed something in this discussion, but you can reproduce bug#15585? How? With this testcase: https://www.postgresql.org/message-id/CAEepm%3D1MvOE-Sfv1chudx5KEmw_qHYrj8F9Og_WmdBRhXSQ%2B%2Bw%40mail.gmail.com ?

By running the queued_alters query multiple times in a loop:
https://www.postgresql.org/message-id/20181231221734.GB25379%40telsasoft.com

I'm able to trigger dsa "ERROR"s with that query on a newly initdb cluster with
only that table.  But I think some servers are more likely to hit it than
others.

I've only tripped on 15585 twice, and only while trying to trigger other DSA
bugs (the working hypothesis is that bug is 2ndary issue which happens after
hitting some other bug).  And not consistently or quickly.

Justin

Commits

  1. Fix rare dsa_allocate() failures due to freepage.c corruption.

  2. Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.

  3. Fix crashes on plans with multiple Gather (Merge) nodes.