| From: | Michael Banck <mbanck(at)gmx(dot)net> |
|---|---|
| To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Jose Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Amcheck verification of GiST and GIN |
| Date: | 2023-02-22 08:51:32 |
| Message-ID: | 63f5d795.170a0220.4c4d2.8257@mx.google.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Feb 02, 2023 at 12:56:47PM -0800, Nikolay Samokhvalov wrote:
> On Thu, Feb 2, 2023 at 12:43 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > I think that that problem should be solved at a higher level, in the
> > program that runs amcheck. Note that pg_amcheck will already do this
> > for B-Tree indexes.
>
> That's a great tool, and it's great it supports parallelization, very useful
> on large machines.
Right, but unfortunately not an option on managed services. It's clear
that this restriction should not be a general guideline for Postgres
development, but it makes the amcheck extension (that is now shipped
everywhere due to being in-code I believe) somewhat less useful for
use-case of checking your whole database for corruption.
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-02-22 08:56:56 | Re: ANY_VALUE aggregate |
| Previous Message | Thomas Munro | 2023-02-22 08:48:10 | Re: Weird failure with latches in curculio on v15 |