Re: Cache lookup errors with functions manipulation object addresses

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cache lookup errors with functions manipulation object addresses
Date: 2019-10-17 01:37:56
Message-ID: 20191017013756.GD5605@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 26, 2019 at 03:52:03PM +0900, Michael Paquier wrote:
> On Wed, Sep 25, 2019 at 09:21:03AM -0300, Alvaro Herrera wrote:
>> On 2019-Sep-24, Michael Paquier wrote:
>>> + * - FORMAT_TYPE_FORCE_NULL
>>> + * if the type OID is invalid or unknown, return NULL instead of ???
>>> + * or such
>>
>> I think FORCE_NULL is a strange name for this flag (and its two
>> siblings); I think something like FORMAT_TYPE_INVALID_AS_NULL is
>> clearer.
>
> Good idea. I see the point.

Got to think more on this one, and your idea is better. So changed
this way.

>> I have still to review this comprehensively, but one thing I don't quite
>> like is the shape of the new regression tests, which seem a bit too
>> bulky ... why not use the style elsewhere in that file, with a large
>> VALUES clause to supply input params for a single query? That would be
>> a lot faster, too.
>
> That makes sense. Here is how I would write it then:
> WITH objects (classid, objid, objsubid) AS (VALUES
> ('pg_class'::regclass, 0, 0), -- no relation
> [ ... ]
> )
> SELECT ROW(pg_identify_object(objects.classid, objects.objid, objects.objsubid))
> AS ident,
> ROW(pg_identify_object_as_address(objects.classid, objects.objid, objects.objsubid))
> AS addr,
> pg_describe_object(objects.classid, objects.objid, objects.objsubid)
> AS descr,
> FROM objects
> ORDER BY objects.classid, objects.objid, objects.objsubid;

That's actually cleaner, so changed as well. Attached is an updated
patch set with the heap_close() calls removed as per the recent report
from Dmitry.
--
Michael

Attachment Content-Type Size
v18-0001-Add-flag-to-format_type_extended-to-enforce-NULL.patch text/x-diff 3.7 KB
v18-0002-Refactor-format-procedure-and-operator-APIs-to-b.patch text/x-diff 7.0 KB
v18-0003-Eliminate-user-visible-cache-lookup-errors-for-o.patch text/x-diff 96.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-10-17 01:47:06 Remaining calls of heap_close/heap_open in the tree
Previous Message Michael Paquier 2019-10-17 01:29:47 Re: Cache lookup errors with functions manipulation object addresses