Re: GIN data corruption bug(s) in 9.6devel

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN data corruption bug(s) in 9.6devel
Date: 2016-04-06 16:52:14
Message-ID: 57053EBE.1050904@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I've tested the v2, v3 and v3.1 of the patch, to see if there are any
> differences. The v2 no longer applies, so I tested it on ee943004. The following
> table shows the total duration of the data load, and also sizes of the two GIN
> indexes.
>
> duration (sec) subject body
> ---------------------------------------------------------------
> v2 1290 23 MB 684 MB
> v3 1360 24 MB 487 MB
> v3.1 1360 24 MB 488 MB
Thank you very much.

Hmm. v3 is a just rebased version of v2, v3.1 hasn't unlock/lock cycle during
cleanup, just to become similar to Jeff's pending lock patch. In theory, v2 and
v3 should be very close, v3.1 should be close to pending_lock.

I'm inclining to push v3.1 as one of two winners by size/performance and, unlike
to pending lock patch, it doesn't change an internal logic of lock machinery.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-04-06 16:55:41 Re: insufficient qualification of some objects in dump files
Previous Message Teodor Sigaev 2016-04-06 16:28:53 Re: [PATH] Jsonb, insert a new value into an array at arbitrary position