| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Injection points: preloading and runtime arguments |
| Date: | 2024-07-16 04:09:21 |
| Message-ID: | ZpXycecyFA7yJ6SN@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 10, 2024 at 01:16:15PM +0900, Michael Paquier wrote:
> You mean with something that does a injection_point_cache_get()
> followed by a callback run if anything is found in the local cache?
> Why not. Based on what you have posted at [1], it looks like this had
> better check the contents of the cache's generation with what's in
> shmem, as well as destroying InjectionPointCache if there is nothing
> else, so there's a possible dependency here depending on how much
> maintenance this should do with the cache to keep it consistent.
Now that 86db52a5062a is in the tree, this could be done with a
shortcut in InjectionPointCacheRefresh(). What do you think about
something like the attached, with your suggested naming?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-INJECTION_POINT_CACHED.patch | text/x-diff | 8.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2024-07-16 04:34:52 | Re: CI, macports, darwin version problems |
| Previous Message | Amit Kapila | 2024-07-16 03:59:46 | Re: long-standing data loss bug in initial sync of logical replication |