Re: Patch queue triage

From: Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Patch queue triage
Date: 2007-05-07 12:47:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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
> > for prime time. At this point we could accept a patch that makes
> > 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
> > 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

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

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

Best Regards;

Koichi Suzuki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-05-07 13:02:55 Re: plperl vs. bytea
Previous Message Zdenek Kotala 2007-05-07 12:47:14 Re: New idea for patch tracking