Re: How to recover from compressed wal archieve in windows

At Wed, 20 May 2020 19:25:50 -0700, Adrian Klaver  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