On 08/27/2014 02:56 PM, marten.svantesson@ticket.se wrote:
> The following bug has been logged on the website:
>
> Bug reference: 11280
> Logged by: Mårten Svantesson
> Email address: marten.svantesson@ticket.se
> PostgreSQL version: 9.4beta2
> Operating system: RHEL 6 kernel 2.6.32
> Description:
>
> As can be seen below one crash occurred during an insert to a table with a
> gin index. (The table actually has 2 gin indexes.) The insert is done from
> an import job where several inserts may be done in parallel. Also a similar
> import is executed concurrently in another database of the cluster.
>
> The crash hasn't happened to me with a clean index (reindex recently done).
> So I can not give an exact step by step account of how to reproduce this.
> The database was migrated from 9.3 with pg_update, but after that both
> reindex and analyze full has been done.
>
> As you can see auto explain is enabled, but I have experienced segmentation
> faults in 9.4 without it enabled. This was before I had enabled core dumps
> so if it was the exact same error I don't know. To get debug symbols I
> compiled from the source tarball of 9.4beta2. Configure was run with
>
> ./configure --without-readline --enable-cassert --enable-debug CFLAGS="-ggdb
> -fno-omit-frame-pointer"
>
> The gin indexes on this table (and the whole database) are
>
> CREATE INDEX offer_departurecode_o_badges_idx
> ON offer
> USING gin
> (departurecode_o, badges);
>
> CREATE INDEX offer_badges_idx
> ON offer
> USING gin
> (badges);
>
> where departurecode_o is defined as character varying(255) and badges as
> bigint[]. The number of distinct values of departurecode_o is low: 26 in a
> table with a bit over 2 million rows. The badges column is not present in
> the insert.
>
> # gdb /usr/pgsql-9.4/bin/postgres core.17901
> <snip>
> Core was generated by `postgres: test test_se xxx.xxx.xxx.xxx(41959) INSERT
> '.
> Program terminated with signal 11, Segmentation fault.
> #0 0x0000000000473e04 in dataPlaceToPageLeaf (btree=0x7fff50edab40,
> buf=66863, stack=0x2c520f0, insertdata=0x7fff50edab30,
> prdata=0x7fff50edaa20, newlpage=0x7fff50edaa18, newrpage=0x7fff50edaa10) at
> gindatapage.c:645
> 645 segsize = SizeOfGinPostingList(lastleftinfo->seg);
Hmm. What seems to be happening is that this code that chooses the best
split location doesn't take into account that the list of posting lists
it's walking through can contain placeholders for posting lists that
were deleted altogether (e.g. because it was merged with the next list).
The SizeOfGinPostingList call fails for such items.
So, this is not related to pg_upgrade or autoexplain, but a
garden-variety bug in the page-splitting code. I was able to reproduce
this with the attached script.
I have committed a fix, which will appear in the next 9.4 beta release
(of if there isn't any more betas, the final release). Thanks for the
report!
- Heikki