Re: Handling GIN incomplete splits

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Handling GIN incomplete splits
Date: 2013-12-02 17:41:07
Message-ID: CAMkU=1zdjY=O239VeBfUuQEyGNXZGnW-e9zGdnz+v2CRsOe7uQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 2, 2013 at 1:26 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com>wrote:

> On 12/01/2013 10:40 PM, Jeff Janes wrote:
>
>> On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>
>> The commit 04eee1fa9ee80dabf7 of this series causes a self-deadlock in
>>> the
>>> LWLock code during the operation below, with it trying to take
>>> an LW_EXCLUSIVE on a high, even-numbered lockid when it already holds the
>>> same lockid.
>>>
>>> CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)
>>> WITH (FASTUPDATE=OFF);
>>>
>>> It happens pretty reliably using osm2pgsql.
>>>
>>> I will try to come up with a simple reproducible demonstration, and stack
>>> trace, over the weekend.
>>>
>>
>> Whatever the problem, it seems to have been fixed in ce5326eed386959aa,
>> "More GIN refactoring".
>>
>
> That's good, I guess :-). Thanks for the testing. Did you import the full
> planet.osm? I tried with a subset containing just Finland, but didn't see
> any problems.
>
>
I used Antarctica. I don't have the RAM to process the full planet, or the
bandwidth to download it very easily.

Do you think it is worth chasing down where the problem was, to make sure
it was truly fixed rather than simply changed in a way that happens not to
trigger any more in this situation?

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-12-02 17:44:08 Re: Trust intermediate CA for client certificates
Previous Message Tom Lane 2013-12-02 17:26:25 Re: Draft release notes for 9.3.2