Re: Patch queue triage

Поиск
Список
Период
Сортировка
От Koichi Suzuki
Тема Re: Patch queue triage
Дата
Msg-id 463F1FD3.5000103@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Patch queue triage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Sorry for late responce due to very long vacation season in Japan.

Tom Lane wrote:

> > * Re: [PATCHES] [HACKERS] Full page writes improvement, code update
> >        /Koichi Suzuki/
> >
> > I feel that we have to insist that this be modified to not create
any WAL
> > bloat in the pre-compression form.  That will be more efficient and will
> > avoid the whole argument about whether a switch is needed.  There
was also
> > doubt about whether the external programs (pg_compresslog etc) were
ready
> > for prime time.  At this point we could accept a patch that makes
whatever
> > small tweaks are needed to ensure that an incremental-format WAL record
> > can be extracted from a full-page-write record, at least for the most
> > common WAL record types for which compression is actually important.  I
> > think the actual compression/decompression programs could undergo
further
> > development on pgfoundry with an eye to merging them into core
before 8.4
> > release.

As suggested by Tom, I agree that WAL should not include "both" full
page write and incremental (logical) log.   I began to examine WAL
record format to see if incremental log can be made from full page
writes.   It will be okay even before 8.4, if simplified patch to the
core is accepted.   I will post simplified patch to the core as follows:

1. Mark the flag to indicate that the WAL record is compressable from
full page writes to incremental log.  This flag will be set if
a) It is not written during the hot backup, and
b) Archive command is active, and
c) WAL contains full page writes, and
d) full_page_writes=on.
No logical log will be written to WAL in this case, and
2. During recovery, xl_tot_len check will be skipped for compressed WAL
records.

With this patch, compress/decompress can be developped outside the core.I'd like to post them to PG foundary first for
thereview for 8.4.
 

I'd be very grateful if this patch can be considered again.

Best Regards;

------------
Koichi Suzuki


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

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: New idea for patch tracking
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: plperl vs. bytea