Thread: 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