Re: [REVIEW] Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [REVIEW] Re: Compression of full-page-writes
Date
Msg-id CAB7nPqTz3yxRqew3A=sSbFRED2=pcQGWEbN_mHPhV8e=_XxN0g@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] Re: Compression of full-page-writes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Nov 25, 2014 at 10:48 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>
>> Exposing compression and decompression APIs of pglz makes possible its
>> use by extensions and contrib modules. pglz_decompress contained a call
>> to elog to emit an error message in case of corrupted data. This function
>> is changed to return a boolean status to let its callers return an error
>> instead.
>
> I think pglz_compress belongs into src/common instead.  It
> seems way too high-level for src/port.
OK. Sounds fine to me.

> Isn't a simple boolean return value too simple-minded?  Maybe an enum
> would be more future-proof, as later you might want to add more values,
> say distinguish between different forms of corruption, or fail due to
> out of memory, whatever.
Hm. I am less sure about that. If we take this road we should do
something similar for the compression portion as well.
-- 
Michael



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: tracking commit timestamps
Next
From: Stephen Frost
Date:
Subject: Re: Transient failure of rowsecurity regression test