Re: Handling GIN incomplete splits - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Handling GIN incomplete splits
Date
Msg-id CAMkU=1zdjY=O239VeBfUuQEyGNXZGnW-e9zGdnz+v2CRsOe7uQ@mail.gmail.com
Whole thread Raw
In response to Re: Handling GIN incomplete splits  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers

On Mon, Dec 2, 2013 at 1:26 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 12/01/2013 10:40 PM, Jeff Janes wrote:
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes <jeff.janes@gmail.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Draft release notes for 9.3.2
Next
From: Bruce Momjian
Date:
Subject: Re: Trust intermediate CA for client certificates