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.klaver@xxxxxxxxxxx
