Re: finding changed blocks using WAL scanning - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: finding changed blocks using WAL scanning
Date
Msg-id 20190420131815.wj3gdcoh5uphv2yu@momjian.us
Whole thread Raw
In response to Re: finding changed blocks using WAL scanning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: finding changed blocks using WAL scanning
List pgsql-hackers
On Sat, Apr 20, 2019 at 12:09:42AM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2019 at 5:47 PM Bruce Momjian <bruce@momjian.us> wrote:
> > How would the modblock file record all the modified blocks across
> > restarts and crashes?  I assume that 1G of WAL would not be available
> > for scanning.  I suppose that writing a modblock file to some PGDATA
> > location when WAL is removed would work since during a crash the
> > modblock file could be updated with the contents of the existing pg_wal
> > files.
> 
> I think you've got to prevent the WAL from being removed until a
> .modblock file has been written.  In more detail, you should (a) scan
> all the WAL segments that will be summarized in the .modblock file,
> (b) write the file under a temporary name, (c) fsync it, (d) rename it
> into place, (e) fsync it again, and (f) then allow those WAL segments
> to be removed, if they are otherwise eligible to be removed.

Makes sense.  So when you are about to remove WAL, you create the
.modblock files for all complete WAL files and only create a new one
when you are about to remove a WAL that was not in a previous .modblock
file.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: refactoring - share str2*int64 functions
Next
From: Bruce Momjian
Date:
Subject: Re: finding changed blocks using WAL scanning