From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrus <kobruleht2(at)hot(dot)ee>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How to recover from compressed wal archieve in windows |
Date: | 2020-05-21 02:25:50 |
Message-ID: | 1b0b4e55-8206-903e-89aa-3dc2ef4f46fb@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
> --
> Michael
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-05-21 04:38:11 | Re: How to recover from compressed wal archieve in windows |
Previous Message | Michael Paquier | 2020-05-21 01:27:38 | Re: How to recover from compressed wal archieve in windows |