Re: Change RangeVarGetRelidExtended() to take flags argument?
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2018-03-06T01:06:59Z
Lists: pgsql-hackers
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. > But having to mess with the semantics of RangeVarGetRelidExtended seems > like a good reason not to go down this path... 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 that's any better. Or just add RangeVarGetRelidExtended2() :) Greetings, Andres Freund
Commits
-
Add SKIP_LOCKED option to RangeVarGetRelidExtended().
- 3e256e550672 11.0 landed
-
Combine options for RangeVarGetRelidExtended() into a flags argument.
- d87510a524f3 11.0 landed