Re: [HACKERS] Placement of InvokeObjectPostAlterHook calls
Robert Haas writes: > On Fri, Jan 6, 2017 at 12:53 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Placement of InvokeObjectPostAlterHook calls
On Fri, Jan 6, 2017 at 12:53 PM, Tom Lane 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 wonder exactly what expectations a > post-alter hook function could have about cache coherency, or indeed if > there's any clarity at all about what such a hook might do. For instance, > it looks to me like the hook would generally need to do a > CommandCounterIncrement in order to be able to "see" the update it's being > called for, and I'm unsure that that would be safe at every call site. > Is that supposed to be allowed, or are we expecting that object access > hooks are only going to do open-loop actions that don't rely on the > details of the change? 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. > I suppose this fits in well with our grand tradition of not documenting > hooks at all, but for a set of hooks as invasive as these are, I think > we ought to do better. I would personally be in favor of documenting all of our hooks, including these. That's a lot of work and I don't have time to do it real soon, but I think it's a worthwhile goal and I'd be willing to contribute to the effort. I think they ought to be documented in the SGML documentation near other things that pertain to server extensibility. However, I'm pretty sure you've shot down these kinds of ideas in the past. If you've revised your opinion, swell. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Placement of InvokeObjectPostAlterHook calls
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 wonder exactly what expectations a post-alter hook function could have about cache coherency, or indeed if there's any clarity at all about what such a hook might do. For instance, it looks to me like the hook would generally need to do a CommandCounterIncrement in order to be able to "see" the update it's being called for, and I'm unsure that that would be safe at every call site. Is that supposed to be allowed, or are we expecting that object access hooks are only going to do open-loop actions that don't rely on the details of the change? I suppose this fits in well with our grand tradition of not documenting hooks at all, but for a set of hooks as invasive as these are, I think we ought to do better. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers