Re: Placement of InvokeObjectPostAlterHook calls

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Placement of InvokeObjectPostAlterHook calls
Date: 2017-01-10 18:27:13
Message-ID: 20921.1484072833@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 6, 2017 at 12:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> While reviewing Etsuro-san's patch to force replanning after FDW option
>> changes, I noticed that there is a great lack of consistency about where
>> InvokeObjectPostAlterHook calls have been placed relative to other actions
>> such as forced relcache invals.

> I remember working pretty hard to make this consistent when that code
> went in. In particular, I think the rule I tried to follow was to
> place the hooks just after the code that injects dependencies. I
> don't know whether the inconsistencies you're seeing are due to (1)
> that being a poor rule of thumb, (2) that rule of thumb not being
> consistently followed at the time the original patch was committed, or
> (3) subsequent drift.

Well, what I was concerned about was specifically placement relative
to cache-invalidation calls. But on reflection it may not matter, since
those really don't do anything except queue up actions to be taken at the
next CommandCounterIncrement boundary. If we allowed the PostAlterHook
functions to do a CommandCounterIncrement then it would be problematic,
but I since found some comments indicating that they shouldn't do that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-01-10 18:31:29 Re: pageinspect: Hash index support
Previous Message Robert Haas 2017-01-10 17:51:57 Re: RustgreSQL