| 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: | Whole Thread | Raw Message | 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 |