Re: Amcheck: do rightlink verification with lock coupling

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Amcheck: do rightlink verification with lock coupling
Date: 2020-01-11 01:45:38
Message-ID: 20200111014538.y4u6fynjeha2nml6@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 12, 2019 at 10:16:12AM -0300, Alvaro Herrera wrote:
>On 2019-Sep-12, Andrey Borodin wrote:
>
>> This patch violates one of amcheck design principles: current code
>> does not ever take more than one page lock. I do not know: should we
>> hold this rule or should we use more deep check?
>
>The check does seem worthwhile to me.
>
>As far as I know, in btree you can lock the right sibling of a page
>while keeping lock on the page itself, without risk of deadlock. So I'm
>not sure what's the issue with that. This is in the README:
>
> In most cases we release our lock and pin on a page before attempting
> to acquire pin and lock on the page we are moving to. In a few places
> it is necessary to lock the next page before releasing the current one.
> This is safe when moving right or up, but not when moving left or down
> (else we'd create the possibility of deadlocks).
>
>I suppose Peter was concerned about being able to run amcheck without
>causing any trouble at all for concurrent operation; maybe we can retain
>that property by making this check optional.
>

Peter, any opinion on this proposed amcheck patch? In the other thread
[1] you seemed to agree this is worth checking, and Alvaro's proposal to
make this check optional seems like a reasonable compromise with respect
to the locking.

[1] https://www.postgresql.org/message-id/flat/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1(at)yandex-team(dot)ru

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-01-11 01:52:53 Re: Add FOREIGN to ALTER TABLE in pg_dump
Previous Message Michael Paquier 2020-01-11 01:41:03 Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema