On Wed, Dec 21, 2011 at 03:16:39PM -0500, Robert Haas wrote:
> On Tue, Dec 20, 2011 at 8:14 PM, Noah Misch wrote:
> > RangeVarCallbackForAlterRelation() does not preserve ALTER TABLE's refusal
> > to
> > operate on foreign tables.
>
> I should probably fix that, but I'm wondering if I ought to f
On Tue, Dec 20, 2011 at 8:14 PM, Noah Misch wrote:
>> I also notice that cluster() - which doesn't have a callback - has
>> exactly the same needs as ReindexRelation() - which does. So that
>> case can certainly share code; though I'm not quite sure what to call
>> the shared callback, or which f
On Mon, Dec 19, 2011 at 11:52:54PM -0500, Robert Haas wrote:
> After staring at this for quite a while longer, it seemed to me that
> the logic for renaming a relation was similar enough to the logic for
> changing a schema that the two calbacks could reasonably be combined
> using a bit of conditi
On Mon, Dec 19, 2011 at 3:12 PM, Noah Misch wrote:
> I'm satisfied that you and I have a common understanding of the options and
> their respective merits. There's plenty of room for judgement in choosing
> which merits to seize at the expense of others. Your judgements here seem
> entirely reas
On Mon, Dec 19, 2011 at 01:43:18PM -0500, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch wrote:
> > Here's the rule I used: the pre-lock checks must prove that the user could,
> > by
> > some command working as-designed, have taken a lock at least as strong as
> > the
> > one
On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch wrote:
> Here's the rule I used: the pre-lock checks must prove that the user could, by
> some command working as-designed, have taken a lock at least as strong as the
> one we're about to acquire. How does that work out in practice? Relation
> owners
On Mon, Dec 19, 2011 at 10:11:23AM -0500, Robert Haas wrote:
> On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch wrote:
> >> I agree, but my point is that so far we have no callbacks that differ
> >> only in that detail. ?I accept that we'd probably want to avoid that.
> >
> > To illustrate what I had
On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch wrote:
>> I agree, but my point is that so far we have no callbacks that differ
>> only in that detail. I accept that we'd probably want to avoid that.
>
> To illustrate what I had in mind, here's a version of your patch that has five
> callers sharing
On Thu, Dec 15, 2011 at 07:04:20PM -0500, Robert Haas wrote:
> On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch wrote:
> > It also seems my last explanation didn't convey the point. ?Yes, nearly
> > every
> > command has a different set of permissions checks. ?However, we don't
> > benefit
> > equally
On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch wrote:
> It also seems my last explanation didn't convey the point. Yes, nearly every
> command has a different set of permissions checks. However, we don't benefit
> equally from performing each of those checks before acquiring a lock.
> Consider renam
On Fri, Dec 09, 2011 at 03:43:19PM -0500, Robert Haas wrote:
> On Wed, Dec 7, 2011 at 8:42 AM, Noah Misch wrote:
> > It narrows the window for race conditions of that genesis, but isn't doing
> > so
> > an anti-feature? ?Even if not, doing that _only_ in RemoveRelations() is
> > odd.
>
> I dunn
On Wed, Dec 7, 2011 at 8:42 AM, Noah Misch wrote:
> It narrows the window for race conditions of that genesis, but isn't doing so
> an anti-feature? Even if not, doing that _only_ in RemoveRelations() is odd.
I dunno. I was just reluctant to change things without a clear reason
for doing so, an
On Tue, Dec 06, 2011 at 04:02:31PM -0500, Robert Haas wrote:
> On Mon, Dec 5, 2011 at 2:09 AM, Noah Misch wrote:
> >> ? ? ? ? ? ? ? AcceptInvalidationMessages();
> >
> > The above call can go away, now.
>
> Doesn't that still protect us against namespace-shadowing issues?
> RangeVarGetRelid doesn
On Mon, Dec 5, 2011 at 2:09 AM, Noah Misch wrote:
> Your committed patch looks great overall. A few cosmetic points:
Thanks for the review.
> That last sentence needs a word around "might things".
Fixed.
>> AcceptInvalidationMessages();
>
> The above call can go away, now.
Does
On Thu, Nov 24, 2011 at 10:54:50AM -0500, Robert Haas wrote:
> All right, here's an updated patch, and a couple of follow-on patches.
Your committed patch looks great overall. A few cosmetic points:
> --- a/src/backend/catalog/namespace.c
> +++ b/src/backend/catalog/namespace.c
> @@ -309,6 +313
On Fri, Nov 18, 2011 at 9:12 AM, Noah Misch wrote:
> Good call.
All right, here's an updated patch, and a couple of follow-on patches.
I updated the main patch (rangevargetrelid-callback-v2.patch) per
previous discussion. I also added a "callback_arg" argument to the
RangeVarGetRelidExtended(),
On Fri, Nov 18, 2011 at 08:58:30AM -0500, Robert Haas wrote:
> On Fri, Nov 18, 2011 at 8:37 AM, Noah Misch wrote:
> > I count 1/25 callers overriding nowait and 3/25 overriding missing_ok. ?So,
> > it's
> > looking like a less-common override than the callback function will come to
> > be.
>
>
On Fri, Nov 18, 2011 at 8:37 AM, Noah Misch wrote:
> I count 1/25 callers overriding nowait and 3/25 overriding missing_ok. So,
> it's
> looking like a less-common override than the callback function will come to
> be.
Yeah, you're probably right. However, I think there's another good
reason
On Thu, Nov 17, 2011 at 11:49:06PM -0500, Robert Haas wrote:
> On Thu, Nov 17, 2011 at 10:48 PM, Noah Misch wrote:
> > On Thu, Nov 17, 2011 at 08:59:58PM -0500, Robert Haas wrote:
> >> --- a/src/include/catalog/namespace.h
> >> +++ b/src/include/catalog/namespace.h
> >> @@ -47,9 +47,15 @@ typedef
On Thu, Nov 17, 2011 at 10:48 PM, Noah Misch wrote:
> On Thu, Nov 17, 2011 at 08:59:58PM -0500, Robert Haas wrote:
>> On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
>> wrote:
>> > Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
>> >> The trouble is, I'm not quite sure how
On Thu, Nov 17, 2011 at 08:59:58PM -0500, Robert Haas wrote:
> On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
> >> The trouble is, I'm not quite sure how to do that. ?It seems like
> >> permissions checks and loc
On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
>> The trouble is, I'm not quite sure how to do that. It seems like
>> permissions checks and lock-the-heap-for-this-index should be done in
>> RangeVarGetRelid() just a
Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
> The trouble is, I'm not quite sure how to do that. It seems like
> permissions checks and lock-the-heap-for-this-index should be done in
> RangeVarGetRelid() just after the block that says "if (retry)" and
> just before the
In commit 4240e429d0c2d889d0cda23c618f94e12c13ade7, we modified
RangeVarGetRelid() so that it acquires a lock on the target relation
"atomically" with respect to the name lookup. Since we lock OIDs, not
names, that's not possible, strictly speaking, but the idea is that we
detect whether any inval
24 matches
Mail list logo
