Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Mar 14, 2019 at 9:26 AM Antonin Houska <ah@cybertec.at> wrote:
> > > Hint bits also rely on this principle. I thought there might be some
> > > interaction between this work and wal_log_hints for this reason, but I see
> > > nothing of that sort in the patch.
> >
> > I'm not sure if the hint bit is still a problem if we first copy the shared
> > buffer to backend-local memory and encrypt it there. That's what the patch
> > does.
>
> That has the same problem that I described in the previous paragraph,
> except for the relation data files rather than the WAL itself. See
> the manual's description of wal_log_hints:
>
> <para>
> When this parameter is <literal>on</literal>, the
> <productname>PostgreSQL</productname>
> server writes the entire content of each disk page to WAL during the
> first modification of that page after a checkpoint, even for
> non-critical modifications of so-called hint bits.
> </para>
>
> For encryption to work, you need that. A hint bit write might convert
> the page to garbage, just as in the previous example, and this option
> make sure that if that happens, there will be an FPW, allowing you to
> recover...
I think I finally understand. Originally I thought the question is how to
compute correct page checksum while the hint bits can be changed w/o exclusive
lock on the buffer. Now I realize that it's more about *recovery*: if the hint
bit change is followed by a torn page write, the hint bit can get changed on
disk but the checksum might not get updated. The wrong checksum is detected
during recovery, but if XLOG does not contain the corresponding full page
image, we're not able to recover.
And with encryption, the consequence is even worse because torn page write
causes not only wrong checksum of otherwise useful page, but really damaged
page.
I'll enforce the FPW in the next version of the patch.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com