Re: Making pg_standby compression-friendly

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Making pg_standby compression-friendly
Дата
Msg-id 4900989E.3050103@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Making pg_standby compression-friendly  ("Koichi Suzuki" <koichi.szk@gmail.com>)
Список pgsql-hackers
Koichi Suzuki wrote:
> In terms of compress/decompress WAL in archive/restore, please take a
> look at my project pglesslog,
> http://pgfoundry.org/projects/pglesslog/
> 
> This project compresses WAL segment by replacing full page writes with
> corresponding incremental logs.   When restored, it inserts dummy WAL
> record to maintain LSN and file size.
> 
> This can be applied to log-shipping mechanism, asynchronous or synchronous.

I believe Charles' question was: how do you hook that decompression into 
pg_standby? I suggested that whatever script is run on the standby 
server to copy xlog files to the archive location, should also call the 
decompression program, like pglesslog, but apparently there is no such 
script in his setup. How would you set up a standby server, using 
pg_lesslog?

> 2008/10/23 Charles Duffy <charles@dyfis.net>:
>> Howdy, all.
>>
>> I'm interested in compressing archived WAL segments in an environment
>> set up for PITR in the interests of reducing both network traffic and
>> storage requirements. However, pg_standby presently checks file sizes,
>> requiring that an archive segment be exactly the right size to be
>> considered valid. The idea of compressing log segments is not new --
>> the clearxlogtail project in pgfoundry provides a tool to make such
>> compression more effective, and is explicitly intended for said
>> purpose -- but as of 8.3.4, pg_standby appears not to support such
>> environments; I propose adding such support.
>>
>> To allow pg_standby to operate in an environment where archive
>> segments are compressed, two behaviors are necessary:
>>
>>  - suppressing the file-size checks. This puts the onus on the user to
>> create these files via an atomic mechanism, but is necessary to allow
>> compressed files to be considered.
>>  - allowing a custom restore command to be provided. This permits the
>> user to specify the mechanism to be used to decompress the segment.
>> One bikeshed is determining whether the user should pass in a command
>> suitable for use in a pipeline or a command which accepts input and
>> output as arguments.
>>
>> A sample implementation is attached, intended only to kickstart
>> discussion; I'm not attached to either its implementation or its
>> proposed command-line syntax.
>>
>> Thoughts?
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>>
>>
> 
> 
> 


--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Koichi Suzuki"
Дата:
Сообщение: Re: Making pg_standby compression-friendly
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Any reason to have heap_(de)formtuple?