From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Minor cleanup for search path cache |
Date: | 2024-01-02 19:20:24 |
Message-ID: | f90a779b4a301d3ff380c8ffa390005d541aa09f.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2024-01-01 at 16:38 -0500, Tom Lane wrote:
> I happened to notice that there is a not-quite-theoretical crash
> hazard in spcache_init(). If we see that SPCACHE_RESET_THRESHOLD
> is exceeded and decide to reset the cache, but then nsphash_create
> fails for some reason (perhaps OOM), an error will be thrown
> leaving the SearchPathCache pointer pointing at already-freed
> memory.
Good catch, thank you. I tried to avoid OOM hazards (e.g. b282fa88df,
8efa301532), but I missed this one.
> I also observed that the code seems to have been run through
> pgindent without fixing typedefs.list, making various places
> uglier than they should be.
>
> The attached proposed cleanup patch fixes those things and in
> passing improves (IMO anyway) some comments. I assume it wasn't
> intentional to leave two copies of the same comment block in
> check_search_path().
Looks good to me.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-01-02 19:30:03 | Re: Minor cleanup for search path cache |
Previous Message | Melanie Plageman | 2024-01-02 18:47:07 | Re: Eager page freeze criteria clarification |