pgsql: Fix crash when ALTER TABLE recreates indexes on partitions
Fix crash when ALTER TABLE recreates indexes on partitions
The skip_build flag was not being passed correctly when recursing to
indexes on partitions, leading to attempts to rebuild indexes when they
were not yet ready to be rebuilt.
Reported-by: Rajkumar Raghuwanshi
Discussion: /messages/by-id/CAKcux6mxNCGsgATwf5CGMF8g4WSupCXicCVMeKUTuWbyxHOMsQ@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/41372071dfaab97a1a8dca83e32b88413460f477
Modified Files
--------------
src/backend/commands/indexcmds.c | 2 +-
src/test/regress/expected/indexing.out | 8 ++++++++
src/test/regress/sql/indexing.sql | 9 +++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Fix crash when ALTER TABLE recreates indexes on partitions
So ... buildfarm member skink has been reporting a valgrind failure
during initdb since this patch went in. However, I'm unable to reproduce
such a failure here, and it's less than obvious how this particular patch
could have caused a problem, and skink's report is pretty useless because
it's providing only a numeric stack trace. Thoughts?
regards, tom lane
On 2018-Jun-30, Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Fix crash when ALTER TABLE recreates indexes on partitions
So ... buildfarm member skink has been reporting a valgrind failure
during initdb since this patch went in. However, I'm unable to reproduce
such a failure here, and it's less than obvious how this particular patch
could have caused a problem, and skink's report is pretty useless because
it's providing only a numeric stack trace. Thoughts?
Actually, older branches are failing in the same way, so it's not my
patch that caused it to fail. Something must have changed in the system ...
Andres?
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018-07-04 13:15:19 -0400, Alvaro Herrera wrote:
On 2018-Jun-30, Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Fix crash when ALTER TABLE recreates indexes on partitions
So ... buildfarm member skink has been reporting a valgrind failure
during initdb since this patch went in. However, I'm unable to reproduce
such a failure here, and it's less than obvious how this particular patch
could have caused a problem, and skink's report is pretty useless because
it's providing only a numeric stack trace. Thoughts?Actually, older branches are failing in the same way, so it's not my
patch that caused it to fail. Something must have changed in the system ...
Andres?
I spent a fair amount of time trying to dig into this. It appears to be
related to a binutils update. Everything built with a binutils version <
2.30.90.20180627-1 (in my case 2.30-22) works correctly with
valgrind. If rebuilt after an upgrade it doesn't. Still trying to
narrow down further.
Greetings,
Andres Freund
On 2018-07-04 20:33:05 -0700, Andres Freund wrote:
On 2018-07-04 13:15:19 -0400, Alvaro Herrera wrote:
On 2018-Jun-30, Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Fix crash when ALTER TABLE recreates indexes on partitions
So ... buildfarm member skink has been reporting a valgrind failure
during initdb since this patch went in. However, I'm unable to reproduce
such a failure here, and it's less than obvious how this particular patch
could have caused a problem, and skink's report is pretty useless because
it's providing only a numeric stack trace. Thoughts?Actually, older branches are failing in the same way, so it's not my
patch that caused it to fail. Something must have changed in the system ...
Andres?I spent a fair amount of time trying to dig into this. It appears to be
related to a binutils update. Everything built with a binutils version <
2.30.90.20180627-1 (in my case 2.30-22) works correctly with
valgrind. If rebuilt after an upgrade it doesn't. Still trying to
narrow down further.
FWIW, I've reported this as a bug to debian. And figured out in the
course of collecting the necessary information that forcing gcc to use
the gold linker works around the issue. Started a run on skink with
that, hopefully that resolves the issue.
Greetings,
Andres Freund