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