Обсуждение: 9.4.1 segfault while creating hash index on temporary table
I am seeing this bug on my CentOS 6.6 PostgreSQL 9.4.1 db server (installed from rpms of yum.postgresql.org), as well as on postgresql 9.4.1 from Ubuntu 15.04 repository on my personal laptop. Steps to reproduce: 1. Create any empty database, i.e. echo 'CREATE DATABASE segfault' | psql -U postgres template1 2. bzcat segfault.sql.bz2 | psql -U postgres segfault At this point postgres should crash with segmentation fault and start recovery. If not, drop the database and steps 1 and 2 a couple of times. In my case I have a crash ratio of close to 100%. The stacktrace I extracted with gdb from coredump on CentOS 6.6 server is also attached to this message FIY: Postgresql segfaults on the last line of the attached sql script which creates a hash index on temporary table Swapping hash with btree works well. Also, inserting ANALYZE temp_table in between CREATE TEMP TABLE and CREATE INDEX also prevents segfault. --- Thank you, Artem
Вложения
Artem Ignatyev <cryo28@gmail.com> writes: > I am seeing this bug on my CentOS 6.6 PostgreSQL 9.4.1 db server > (installed from rpms of yum.postgresql.org), as well as on postgresql > 9.4.1 from Ubuntu 15.04 repository on my personal laptop. It's crashing because it's trying to acquire the content_lock on a local buffer, which of course doesn't have one. This appears to have been broken in 8fc23a9e. Oddly, HEAD does not have the problem because it looks like if ((mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK) && !isLocalBuf) { LWLockAcquire(bufHdr->content_lock, LW_EXCLUSIVE); } but the back branches are missing the isLocalBuf bit. regards, tom lane
On 05/13/2015 08:09 AM, Tom Lane wrote: > Artem Ignatyev <cryo28@gmail.com> writes: >> I am seeing this bug on my CentOS 6.6 PostgreSQL 9.4.1 db server >> (installed from rpms of yum.postgresql.org), as well as on postgresql >> 9.4.1 from Ubuntu 15.04 repository on my personal laptop. > > It's crashing because it's trying to acquire the content_lock on a > local buffer, which of course doesn't have one. This appears to have > been broken in 8fc23a9e. Oddly, HEAD does not have the problem because > it looks like > > if ((mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK) && > !isLocalBuf) > { > LWLockAcquire(bufHdr->content_lock, LW_EXCLUSIVE); > } > > but the back branches are missing the isLocalBuf bit. Odd indeed. I must've added that at the last minute to the master-version, but forgot the other branches. Fixed now, thanks for the report and analysis. - Heikki