Re: Handling GIN incomplete splits
| От | Jeff Janes |
|---|---|
| Тема | Re: Handling GIN incomplete splits |
| Дата | |
| Msg-id | CAMkU=1zdjY=O239VeBfUuQEyGNXZGnW-e9zGdnz+v2CRsOe7uQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Handling GIN incomplete splits (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Список | 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: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 по дате отправления: