From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: amcheck (B-Tree integrity checking tool) |
Date: | 2016-08-19 00:53:16 |
Message-ID: | CAM3SWZRne0eeGmW4+aTzNE6Nw9OCnK+PU2baHQe1F6_pNFPMSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 18, 2016 at 5:35 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> This would be packaged from source in my case, but that's no big deal
> :) At least I can see that it is added in the next CF, and that's
> marked as ready for committer for a couple of months now...
If you consider how the code is written, you'll see that it's very
unlikely to destabilize production systems.
Every page is copied into local memory once before being operated on,
and only one buffer lock/pin is held at once (for long enough to do
that copying). If there were bugs in amcheck, it's much more likely
that they'd be "false positive" bugs. In any case, I haven't seen any
issue with the tool itself yet, having now run the tool on thousands
of servers.
I think I'll have a lot more information in about a week, when I've
had time to work through more data.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-08-19 01:01:20 | Re: Fix comment in ATExecValidateConstraint |
Previous Message | Michael Paquier | 2016-08-19 00:49:45 | Re: WIP: About CMake v2 |