From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_verify_checksums and -fno-strict-aliasing |
Date: | 2018-08-30 23:12:14 |
Message-ID: | 20180830231214.vsdcgmo3kjjx2s3j@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-08-30 19:02:15 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > It certainly should be warned about. Practically I don't think it's a
> > problem, because we pretty much always operate on a copy of the page
> > when writing out, as otherwise concurrently set hint bits would be
> > troublesome.
>
> The write end of things is not a problem IMO, since presumably the caller
> would be about to overwrite the checksum field anyway. The issue is for
> reading and/or verifying, where it's much less obvious that clobbering
> the page image is safe.
With "reading" you mean putting the page into the buffercache? If so,
that should be ok, the page isn't yet accessible (BM_VALID isn't set).
I don't think it's possible to do verification from the page in s_b,
because we don't keep the checksum current, so there should never be
calls to do so.
But we probably should still add a comment making clear that the
function modifies the buffer temporarily.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-08-30 23:23:20 | Re: some pg_dump query code simplification |
Previous Message | Tom Lane | 2018-08-30 23:02:15 | Re: pg_verify_checksums and -fno-strict-aliasing |