Re: [REVIEW] Re: Compression of full-page-writes

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [REVIEW] Re: Compression of full-page-writes
Дата
Msg-id CAB7nPqTz3yxRqew3A=sSbFRED2=pcQGWEbN_mHPhV8e=_XxN0g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [REVIEW] Re: Compression of full-page-writes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [REVIEW] Re: Compression of full-page-writes
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: tracking commit timestamps
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Transient failure of rowsecurity regression test