Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W5QfP-00022i-3C for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2014 02:02:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W5QfO-00080n-A0 for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2014 02:02:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W5QfM-00080e-LL for pgsql-hackers@postgresql.org; Tue, 21 Jan 2014 02:02:12 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W5QfK-0002vH-Ad for pgsql-hackers@postgresql.org; Tue, 21 Jan 2014 02:02:12 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 0417C508EE7 for ; Tue, 21 Jan 2014 03:02:07 +0100 (CET) X-Virus-Scanned: G-Hosting.cz + Station.cz + Klenot.cz + Subreg.cz amavisd-new at antispam.gransy.com Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id r8fyXkwVY7vJ for ; Tue, 21 Jan 2014 03:02:08 +0100 (CET) Received: from [192.168.1.227] (ip-78-45-139-138.net.upcbroadband.cz [78.45.139.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tv@fuzzy.cz) by mail.gransy.com (Postfix) with ESMTPSA id 5F82F508EE9; Tue, 21 Jan 2014 03:02:06 +0100 (CET) Message-ID: <52DDD51E.2080408@fuzzy.cz> Date: Tue, 21 Jan 2014 03:02:06 +0100 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Heikki Linnakangas , Alexander Korotkov CC: pgsql-hackers Subject: Re: GIN improvements part 1: additional information References: <52A62771.3070800@vmware.com> <52AEE445.1060206@vmware.com> <52AF837C.3040201@vmware.com> <52B2F5B0.1030809@vmware.com> <52B49C34.8060300@vmware.com> <52D0A947.6050706@fuzzy.cz> <52D478F2.6070005@fuzzy.cz> <52D5E1BC.3000208@fuzzy.cz> <52D9789E.3030202@vmware.com> <52DD6B4B.3050806@vmwar e.com> In-Reply-To: <52DD6B4B.3050806@vmware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 20.1.2014 19:30, Heikki Linnakangas wrote: > > Attached is a yet another version, with more bugs fixed and more > comments added and updated. I would appreciate some heavy-testing of > this patch now. If you could re-run the tests you've been using, > that could be great. I've tested the WAL replay by replicating GIN > operations over streaming replication. That doesn't guarantee it's > correct, but it's a good smoke test. I gave it a try - the OOM error seems to be gone, but now get this PANIC: cannot insert duplicate items to GIN index page This only happens when building the index incrementally (i.e. using a sequence of INSERT statements into a table with GIN index). When I create a new index on a table (already containing the same dataset) it works just fine. Also, I tried to reproduce the issue by running a simple plpgsql loop (instead of a complex python script): DO LANGUAGE plpgsql $$ DECLARE r tsvector; BEGIN FOR r IN SELECT body_tsvector FROM data_table LOOP INSERT INTO idx_table (body_tsvector) VALUES (r); END LOOP; END$$; where data_table is the table with imported data (the same data I mentioned in the post about OOM errors), and index_table is an empty table with a GIN index. And indeed it fails, but only if I run the block in multiple sessions in parallel. regards Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers