At Wed, 20 May 2020 19:25:50 -0700, Adrian Klaver <adrian.klaver@aklaver.com> wrote in
> On 5/20/20 6:27 PM, Michael Paquier wrote:
> > On Wed, May 20, 2020 at 11:36:09AM -0700, Adrian Klaver wrote:
> >> The next problem is that I'm pretty sure a WAL file with *.gz
> >> extension will
> >> not be able to be processed directly by the server. So you are going
> >> to have
> >> to uncompress it at some point before it gets restored.
> > The short answer to that question is no. The backend does not
> > uncompress the segment file. What happens is that the restore command
> > copies the file defined by %f to the location of %p where is gets
> > renamed to RECOVERYXLOG, and we expect the restore command to drop a
> > 16MB file in og_wal/. There is a check on the size, which would fail
> > if the WAL segment is still compressed. This logic is in
> > RestoreArchivedFile() in xlogarchive.c.
>
> I figured that would be the case.
>
> So how is this handled?:
>
> wal_compression (boolean)
>
> When this parameter is on, the PostgreSQL server compresses a full
> page image written to WAL when full_page_writes is on or during a base
> backup. A compressed page image will be decompressed during WAL
> replay. The default value is off. Only superusers can change this
> setting.
Difference from decompression by restore_command?
A WAL (segment) file is filled with multiple WAL records. The "full
page image", which is described to be compressed by the parameter, is
a part of WAL record. A WAL file is filled with maybe-compressed WAL
records and has the same size in the case where wal_compression is on.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
