Re: Online verification of checksums
| От | Magnus Hagander |
|---|---|
| Тема | Re: Online verification of checksums |
| Дата | |
| Msg-id | CABUevEwunDWDYqCJug_=gzzkX1mDgf0BMp67OGFR+cgucz6WdQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Online verification of checksums (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Mon, Mar 4, 2019 at 3:02 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On 3/4/19 4:09 AM, Michael Paquier wrote:
> On Sun, Mar 03, 2019 at 07:58:26AM +0100, Fabien COELHO wrote:
>> I agree that having a server function (extension?) to do a full checksum
>> verification, possibly bandwidth-controlled, would be a good thing. However
>> it would have side effects, such as interfering deeply with the server page
>> cache, which may or may not be desirable.
>
> In what is that different from VACUUM or a sequential scan? It is
> possible to use buffer ring replacement strategies in such cases using
> the normal clock-sweep algorithm, so that scanning a range of pages
> does not really impact Postgres shared buffer cache.
> --
But Fabien was talking about page cache, not shared buffers. And we
can't use custom ring buffer there. OTOH I don't see why accessing the
file through SQL function would behave any differently than direct
access (i.e. what the tool does now).
It shouldn't.
One other thought that I had around this though, which if it's been covered before and I missed it, please disregard :)
The *online* version of the tool is very similar to running pg_basebackup to /dev/null, is it not? Except it doesn't set the cluster to backup mode. Perhaps what we really want is a simpler way to do *that*. That wouldn't necessarily make it a SQL callable function, but it would be a CLI tool that would call a command on a walsender for example.
(We'd of course still need the standalone tool for offline checks)
В списке pgsql-hackers по дате отправления: