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.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 |