Re: Change RangeVarGetRelidExtended() to take flags argument?

On 3/30/18, 7:09 PM, "Andres Freund" wrote: > Pushed. Thanks! Nathan

Re: Change RangeVarGetRelidExtended() to take flags argument?

On 2018-03-30 11:37:19 +0900, Michael Paquier wrote: > On Thu, Mar 29, 2018 at 05:15:14PM -0700, Andres Freund wrote: > > On 2018-03-22 15:45:23 +, Bossart, Nathan wrote: > >> Here is a set of patches for this approach. > > > > To me this looks like a reasonable approach that'd solve the

Re: Change RangeVarGetRelidExtended() to take flags argument?

Hi, On 2018-03-30 17:08:26 +, Bossart, Nathan wrote: > +typedef enum RelidOption > +{ > + RELID_MISSING_OK = 1 << 0, /* don't error if relation doesn't > exist */ > + RELID_NOWAIT = 1 << 1 /* error if relation cannot be locked */ > +} RelidOption; I don't like the

Re: Change RangeVarGetRelidExtended() to take flags argument?

On Thu, Mar 29, 2018 at 05:15:14PM -0700, Andres Freund wrote: > On 2018-03-22 15:45:23 +, Bossart, Nathan wrote: >> Here is a set of patches for this approach. > > To me this looks like a reasonable approach that'd solve the VACUUM > use-case. I think we can live with the API breakage, but

Re: Change RangeVarGetRelidExtended() to take flags argument?

Hi Everyone, On 2018-03-22 15:45:23 +, Bossart, Nathan wrote: > Here is a set of patches for this approach. To me this looks like a reasonable approach that'd solve the VACUUM use-case. I think we can live with the API breakage, but I'd like to have some more comments? Pertinent parts

Re: Change RangeVarGetRelidExtended() to take flags argument?

On 3/5/18, 7:08 PM, "Andres Freund" wrote: > On 2018-03-05 19:57:44 -0500, Tom Lane wrote: >> Andres Freund 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.

Re: Change RangeVarGetRelidExtended() to take flags argument?

On Mon, Mar 05, 2018 at 05:21:11PM -0800, Andres Freund wrote: > Hi, > > On 2018-03-06 10:17:49 +0900, Michael Paquier wrote: > > On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > > > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > > > similar code. It'd

Re: Change RangeVarGetRelidExtended() to take flags argument?

Hi, On 2018-03-06 10:17:49 +0900, Michael Paquier wrote: > On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > > similar code. It'd not be too hard to move RangeVarGetRelidExtended() > > code into

Re: Change RangeVarGetRelidExtended() to take flags argument?

On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > similar code. It'd not be too hard to move RangeVarGetRelidExtended() > code into RangeVarGetRelidInternal() and add > RangeVarGetRelidTryLock(). Not sure if

Re: Change RangeVarGetRelidExtended() to take flags argument?

On 2018-03-05 19:57:44 -0500, Tom Lane wrote: > Andres Freund 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

Re: Change RangeVarGetRelidExtended() to take flags argument?

Andres Freund 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? But having to mess