Thank you, v5 didn't find any issues at all. One thing: for my 29 indexes,
the tool generated output 3.5 GiB. I guess many INFO messages should be
downgraded to something like DEBUG1?
On Fri, Jul 30, 2021 at 2:35 AM Heikki Linnakangas wrote:
> On 29/07/2021 21:34, Nikolay Samokhvalov wrote:
> >
On 29/07/2021 21:34, Nikolay Samokhvalov wrote:
I was trying to check a bunch of GINs on some production after switching
from Ubuntu 16.04 to 18.04 and got many errors. So decided to check for
16.04 first (that is still used on prod for that DB), without any
OS/glibc changes.
On 16.04, I stil
Hello,
First of all, thank you all -- Andrey, Peter, Heikki and others -- for this
work, GIN support in amcheck is *really* needed, especially for OS upgrades
such as from Ubuntu 16.04 (which is EOL now) to 18.04 or 20.04
I was trying to check a bunch of GINs on some production after switching
fr
On 07/08/2020 00:33, Peter Geoghegan wrote:
On Wed, May 27, 2020 at 10:11 AM Grigory Kryachko wrote:
Here is the patch which I (with Andrey as my advisor) built on the top of the
last patch from this thread: https://commitfest.postgresql.org/25/1800/ .
It adds an ability to verify validity of
On Wed, May 27, 2020 at 10:11 AM Grigory Kryachko wrote:
> Here is the patch which I (with Andrey as my advisor) built on the top of the
> last patch from this thread: https://commitfest.postgresql.org/25/1800/ .
> It adds an ability to verify validity of GIN index. It is not polished yet,
> bu
On Wed, Sep 11, 2019 at 04:10:20PM -0700, Peter Geoghegan wrote:
> Why is this not a problem for the new amcheck checks? Maybe this is a
> very naive question. I don't claim to be a GiST expert.
This thread did not receive any updates after a couple of months, and
visibly input was waited from An
On Sun, Sep 8, 2019 at 1:21 AM Andrey Borodin wrote:
> Maybe we should PageGetItemIdCareful() to amcheck.c too?
> I think it can be reused later by GIN entry tree and to some extent by
> SP-GiST.
> SP-GiST uses redirect tuples, but do not store this information in line
> pointer.
Well, the deta
Alvaro, Peter, thanks for working on this!
> 7 сент. 2019 г., в 6:26, Peter Geoghegan написал(а):
>
> On Fri, Sep 6, 2019 at 3:22 PM Peter Geoghegan wrote:
>> I'll take care of it, then.
>
> Attached is v10, which has some comment and style fix-ups, including
> the stuff Alvaro mentioned. It a
On Fri, Sep 6, 2019 at 3:22 PM Peter Geoghegan wrote:
> I'll take care of it, then.
Attached is v10, which has some comment and style fix-ups, including
the stuff Alvaro mentioned. It also adds line pointer sanitization to
match what I added to verify_nbtree.c in commit a9ce839a (we use a
custom
On Fri, Sep 6, 2019 at 2:35 PM Alvaro Herrera from 2ndQuadrant
wrote:
> I'd welcome it more if you did it; thanks.
I'll take care of it, then.
--
Peter Geoghegan
On 2019-Sep-06, Peter Geoghegan wrote:
> On Fri, Sep 6, 2019 at 7:02 AM Alvaro Herrera from 2ndQuadrant
> wrote:
> > Peter, Heikki, are you going to do [at least] one more round of
> > design/functional review?
>
> I didn't plan on it, but somebody probably should. Are you offering to
> commit t
On Fri, Sep 6, 2019 at 7:02 AM Alvaro Herrera from 2ndQuadrant
wrote:
> Peter, Heikki, are you going to do [at least] one more round of
> design/functional review?
I didn't plan on it, but somebody probably should. Are you offering to
commit the patch? If not, I can take care of it.
--
Peter Ge
On 2019-Sep-06, Andrey Borodin wrote:
> Here's rebased version. Changes in v9:
> * adjust to usage of table_open
> * update new extension version
> * check for main fork presence in GiST check too
Cool. On a quick eyeball, your new amcheck.h does not conform to our
conventions: it should not inc
Hi!
> 4 сент. 2019 г., в 2:13, Alvaro Herrera написал(а):
>
> On 2019-Mar-29, Andrey Borodin wrote:
>
>> Here's updated patch with AccessShareLock.
>> I've tried to stress this with combination of random inserts, vaccuums and
>> checks. This process neither failed, nor deadlocked.
>> The patch
On 2019-Mar-29, Andrey Borodin wrote:
> Here's updated patch with AccessShareLock.
> I've tried to stress this with combination of random inserts, vaccuums and
> checks. This process neither failed, nor deadlocked.
> The patch intentionally contains one superflous line to make gist logically
> b
On Thu, Mar 28, 2019 at 11:30 PM Andrey Borodin wrote:
> Here's updated patch with AccessShareLock.
> I've tried to stress this with combination of random inserts, vaccuums and
> checks. This process neither failed, nor deadlocked.
> The patch intentionally contains one superflous line to make gi
> 29 марта 2019 г., в 5:35, Peter Geoghegan написал(а):
>
> On Thu, Mar 28, 2019 at 10:08 AM Andrey Borodin wrote:
Is this really needed? Isn't the ShareLock on the index sufficient? If so,
why?
>>> There may be concurrent inserts? In GiST they can reorder items on page.
>>
>> Look
On Thu, Mar 28, 2019 at 10:08 AM Andrey Borodin wrote:
> >> Is this really needed? Isn't the ShareLock on the index sufficient? If so,
> >> why?
> > There may be concurrent inserts? In GiST they can reorder items on page.
>
> Looks like I've tried to cope with same problem twice:
> v3 of the patc
> 28 марта 2019 г., в 18:35, Andrey Borodin написал(а):
>>
>> Is this really needed? Isn't the ShareLock on the index sufficient? If so,
>> why?
> There may be concurrent inserts? In GiST they can reorder items on page.
Looks like I've tried to cope with same problem twice:
v3 of the patch u
Thanks for looking into this!
> 27 марта 2019 г., в 22:29, Heikki Linnakangas написал(а):
>
> On 27/03/2019 11:51, Andrey Borodin wrote:
>> Hi!
>> Here's new version of GiST amcheck, which takes into account recently
>> committed GiST VACUUM.
>> It tests that deleted pages do not contain any da
On Wed, Mar 27, 2019 at 10:29 AM Heikki Linnakangas wrote:
> Thanks! I had a look, and refactored it quite a bit.
I'm really happy that other people seem to be driving amcheck in a new
direction, without any prompting from me. It's too important to remain
something that only I have contributed to
On 27/03/2019 11:51, Andrey Borodin wrote:
Hi!
Here's new version of GiST amcheck, which takes into account recently committed
GiST VACUUM.
It tests that deleted pages do not contain any data.
Thanks! I had a look, and refactored it quite a bit.
I found the way the recursion worked confusing
Hi!
Here's new version of GiST amcheck, which takes into account recently committed
GiST VACUUM.
It tests that deleted pages do not contain any data.
Also, Heikki's fix applied (wrong OffsetNumberNext(i) replaced by
OffsetNumberNext(o)).
Thanks!
Best regards, Andrey Borodin.
0001-GiST-verif
On 04/03/2019 17:53, Heikki Linnakangas wrote:
I tested this patch with your testing patch from the other thread (after
fixing the above), to leave behind incompletely split pages [1]. It
seems that the amcheck code doesn't expect incomplete splits:
postgres=# SELECT gist_index_parent_check('x_c
There's a little copy-pasto in gist_check_page_keys():
+ for (o = FirstOffsetNumber; o <= parent_maxoff; o =
OffsetNumberNext(i))
Should be "OffsetNumberNext(o)".
I tested this patch with your testing patch from the other thread (after
fixing the above), to leave behin
Hi!
Thanks for this detailed review!
>
> * Note that this "parent then child" lock order seems to not be
> consistent with the general rule for holding concurrent buffer locks
> that is described in the GiST README:
This is correct. I've changed locking order.
When we check target internal pag
On Sun, Feb 17, 2019 at 12:55 AM Andrey Borodin wrote:
> That's true, we cannot avoid locking parent and child page simultaneously to
> check correctness of tuples.
Right.
Some further questions/comments:
* I think that this should be an error:
> + if (GistPageIsLeaf(page))
> + {
Hi Peter!
Sorry for the delay. Here's new version.
> 1 февр. 2019 г., в 4:58, Peter Geoghegan написал(а):
>
> On Tue, Jan 1, 2019 at 2:11 AM Andrey Borodin wrote:
>>> This isn't consistent with what you do within verify_nbtree.c, which
>>> deliberately avoids ever holding more than a single bu
On Thu, Jan 31, 2019 at 03:58:48PM -0800, Peter Geoghegan wrote:
> I think that holding a buffer lock on an internal pages for as long as
> it takes to check all of the child pages is a non-starter. If you
> can't think of a way of not doing that that's race free with a
> relation-level AccessShare
On Tue, Jan 1, 2019 at 2:11 AM Andrey Borodin wrote:
> > This isn't consistent with what you do within verify_nbtree.c, which
> > deliberately avoids ever holding more than a single buffer lock at a
> > time, on general principle. That isn't necessarily a reason why you
> > have to do the same, bu
Hi, Peter!
Thank you for the review!
> 7 дек. 2018 г., в 3:59, Peter Geoghegan написал(а):
>
> On Sun, Sep 23, 2018 at 10:12 PM Andrey Borodin wrote:
> * You do this:
>
>> +/* Check of an internal page. Hold locks on two pages at a time
>> (parent+child). */
>
> This isn't consistent with w
On Sun, Sep 23, 2018 at 10:12 PM Andrey Borodin wrote:
> (0001-GiST-verification-function-for-amcheck-v2.patch)
Thanks for working on this. Some feedback:
* You do this:
> +/* Check of an internal page. Hold locks on two pages at a time
> (parent+child). */
This isn't consistent with what you
Hi!
> 24 сент. 2018 г., в 8:29, Thomas Munro
> написал(а):
>
> On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
>> Here's the patch with amcheck functionality for GiST.
>
> Hi Andrey,
>
> Windows doesn't like it[1]:
Thanks, Thomas! Yes, I've missed that version-dependent macro. Surely
On 2018-09-24 15:29:38 +1200, Thomas Munro wrote:
> On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
> > Here's the patch with amcheck functionality for GiST.
>
> Hi Andrey,
>
> Windows doesn't like it[1]:
>
> contrib/amcheck/verify_gist.c(163): error C2121: '#' : invalid
> character : po
On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
> Here's the patch with amcheck functionality for GiST.
Hi Andrey,
Windows doesn't like it[1]:
contrib/amcheck/verify_gist.c(163): error C2121: '#' : invalid
character : possibly the result of a macro expansion
[C:\projects\postgresql\amche
Hi, hackers!
Here's the patch with amcheck functionality for GiST.
It basically checks two invariants:
1. Every internal tuple need no adjustment by tuples of referenced page
2. Internal page reference or only leaf pages or only internal pages
We actually cannot check all balanced tree invariant
36 matches
Mail list logo
