| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Mark all GUC variable as PGDLLIMPORT |
| Date: | 2021-08-24 18:52:23 |
| Message-ID: | 61253FE7.6010301@anastigmatix.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08/24/21 14:28, Robert Haas wrote:
> cost would, I think, be quite terrible. If you really had to force
> everything through an API, I think what you'd want to do is define an
> API where code can look up a handle object for a GUC using the name of
> the GUC, and then hold onto a pointer to the handle and use that for
> future accesses, so that you don't have to keep incurring the expense
> of a hash table hit on every access. But even if you did that,
> preventing "unauthorized" writes to GUC variables would require a
> function call for every access.
I don't think that's true of the second proposal in [0]. I don't foresee
a noticeable runtime cost unless there is a plausible workload that
involves very frequent updates to GUC settings that are also of interest
to a bunch of extensions. Maybe I'll take a stab at a POC.
Regards,
-Chap
[0] https://www.postgresql.org/message-id/6123C425.3080409%40anastigmatix.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-08-24 19:08:49 | Re: .ready and .done files considered harmful |
| Previous Message | Bruce Momjian | 2021-08-24 18:49:00 | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) |