From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers |
Date: | 2015-01-27 00:11:48 |
Message-ID: | CAM-w4HP=zo_8cBgUsinUN6+Up7Af73pU-HYuWC21f1y-Zi1Ohw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
wrote:
> But one backend can effectively "pin" a buffer more than once, no? If so,
> then ISTM there's some risk that code path A pins and forgets to unpin, but
> path B accidentally unpins for A.
>
The danger is that there's a codepath that refers to memory it doesn't have
a pin on but that there is no actual test in our regression suite that
doesn't actually have a second pin on the same buffer. If there is in fact
no reachable code path at all without the second pin then there's no active
bug, only a bad coding practice. But if there are code paths that we just
aren't testing then that's a real bug.
IIRC CLOBBER_FREED_MEMORY only affects palloc'd blocks. Do we not have a
mode that automatically removes any buffer as soon as it's not pinned? That
seems like it would be a valuable addition.
Fwiw I think our experience is that bugs where buffers are unpinned get
exposed pretty quickly in production. I suppose the same might not be true
for rarely called codepaths or in cases where the buffers are usually
already pinned.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-01-27 00:15:31 | Re: ExplainModifyTarget doesn't work as expected |
Previous Message | Jim Nasby | 2015-01-27 00:10:21 | Re: pg_upgrade and rsync |