Re: [HACKERS] Custom compression methods - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Custom compression methods
Date
Msg-id CAB7nPqSfuxBnsJs4a04M+GZF1AUQoAgTt989n3oJOvGrZS-xXg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Thu, Nov 30, 2017 at 8:30 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On 11/28/2017 02:29 PM, Ildus Kurbangaliev wrote:
>> On Mon, 27 Nov 2017 18:20:12 +0100
>> Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>>
>>> I guess the trick might be -DRANDOMIZE_ALLOCATED_MEMORY (I first
>>> tried without it, and it seemed working fine). If that's the case,
>>> I bet there is a palloc that should have been palloc0, or something
>>> like that.
>>
>> Thanks, that was it. I've been able to reproduce this bug. The
>> attached patch should fix this bug and I've also added recompression
>> when tuples moved to the relation with the compressed attribute.
>>
>
> I've done many tests with fulltext search on the mail archive, using
> different compression algorithm, and this time it worked fine. So I can
> confirm v7 fixes the issue.

Moved to next CF.
-- 
Michael


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Protect syscache from bloating with negative cache entries
Next
From: Michael Paquier
Date:
Subject: Re: WIP: BRIN multi-range indexes