Date: Wed, 27 Mar 2019 03:36:12 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: performance issue in remove_from_unowned_list()
Message-ID: <20190327023612.GC4406@development>
References: <20190310200923.GA4108@alvherre.pgsql>
 <7c599eff-8125-091c-61ef-90e02aa57486@2ndquadrant.com>
 <cdc51a4d-a47c-a514-0db8-a758d3190b4d@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <cdc51a4d-a47c-a514-0db8-a758d3190b4d@2ndquadrant.com>
User-Agent: Mutt/1.11.4+135 (aae3e555) (2019-03-21)
Precedence: bulk

On Thu, Mar 21, 2019 at 02:22:40AM +0100, Tomas Vondra wrote:
> ...
>
>OK, so here is a bit more polished version of the dlist-based patch.
>
>It's almost identical to what I posted before, except that it:
>
>1) undoes the non-working optimization in DropRelationFiles()
>
>2) removes add_to_unowned_list/remove_from_unowned_list entirely and
>just replaces that with dlist_push_tail/dlist_delete
>
>I've originally planned to keep those functions, mostly because the
>remove_from_unowned_list comment says this:
>
>  - * If the reln is not present in the list, nothing happens.
>  - * Typically this would be caller error, but there seems no
>  - * reason to throw an error.
>
>I don't think dlist_delete allows that. But after further inspection of
>all places calling those functions, don't think that can happen.
>
>I plan to commit this soon-ish and backpatch it as mentioned before,
>because I consider it pretty much a fix for b4166911.
>

Aaaaaand committed + backpatched.

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