Horton

Re: Change RangeVarGetRelidExtended() to take flags argument?

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-03-22T15:45:23Z
Lists: pgsql-hackers

Attachments

On 3/7/18, 10:33 AM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 3/5/18, 7:08 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> On 2018-03-05 19:57:44 -0500, Tom Lane wrote:
>>> Andres Freund <andres@anarazel.de> writes:
>>>> One wrinkle in that plan is that it'd not be trivial to discern whether
>>>> a lock couldn't be acquired or whether the object vanished.  I don't
>>>> really have good idea how to tackle that yet.
>>> Do we really care which case applies?
>>
>> I think there might be cases where we do. As expand_vacuum_rel()
>> wouldn't use missing_ok = true, it'd not be an issue for this specific
>> callsite though.
>
> I think it might be enough to simply note the ambiguity of returning
> InvalidOid when skip-locked and missing-ok are both specified.  Even
> if RangeVarGetRelidExtended() did return whether skip-locked or
> missing-ok applied, such a caller would likely not be able to trust
> it anyway, as no lock would be held.

Here is a set of patches for this approach.

Nathan

Commits

  1. Add SKIP_LOCKED option to RangeVarGetRelidExtended().

  2. Combine options for RangeVarGetRelidExtended() into a flags argument.