Re: [v9.3] OAT_POST_ALTER object access hooks - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.3] OAT_POST_ALTER object access hooks
Date
Msg-id CADyhKSV1-JY6KTQCSpd_Np7iL+3ar_31ipZBGM3-UaoX88_oUQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.3] OAT_POST_ALTER object access hooks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [v9.3] OAT_POST_ALTER object access hooks
Re: [v9.3] OAT_POST_ALTER object access hooks
List pgsql-hackers
2012/12/3 Robert Haas <robertmhaas@gmail.com>:
> On Sat, Dec 1, 2012 at 2:57 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> * Do we need OAT_POST_ALTER hook even if no fields were updated
>>   actually? In case when ALTER SET OWNER, it checks object's ownership
>>   only when current and new user-id is not same. Right now, I follow this
>>   manner on OAT_POST_ALTER invocation.
>>   However, I'm inclined to consider the hook should be invoked when no
>>   fields are actually updated also. (It allows extension-side to determine
>>   necessity of processing something.)
>
> I agree.  I think it should always be called.
>
OK, I'll move the point to invoke hooks into outside of the if-block.

>> * When tablespace of relation was changed, it seems to me the point to
>>   invoke OAT_POST_ALTER hook should be "after" ATRewriteTable().
>>   However, it usually long time to rewrite whole the table if it already have
>>   large number of rows. I'm not 100% certain to put hook here, so this
>>   version does not support hook when tablespace changes.
>
> Well, if it's a post-alter hook, it should presumably happen as close
> to the end of processing as possible.   But are you sure that's really
> what you want?  I would think that for SE-Linux you'd be wanting to
> get control much earlier in the process.
>
In my preference, an error shall be raised prior to whole of the table
rewrite stuff; it can take exclusive table lock during possible TB or PB
of disk-i/o. Even if sepgsql got control after all and raise an access
control error, I'm not happy so much. :-(

As we discussed before, it is hard to determine which attributes shall
be informed to extension via object_access_hook, so the proposed
post-alter hook (that allows to compare older and newer versions)
works fine on 99% cases.
However, I'm inclined to handle SET TABLESPACE as an exception
of this scenario. For example, an idea is to define OAT_PREP_ALTER
event additionally, but only invoked very limited cases that takes
unignorable side-effects until system catalog updates.
For consistency of hook, OAT_POST_ALTER event may also ought
to be invoked just after catalog updates of pg_class->reltablespace,
but is_internal=true.

How about your opinion?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



pgsql-hackers by date:

Previous
From: Steve Singer
Date:
Subject: Re: [PATCH 11/14] Introduce wal decoding via catalog timetravel
Next
From: Markus Wanner
Date:
Subject: Re: Review: Extra Daemons / bgworker