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