| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "wangsh(dot)fnst(at)fujitsu(dot)com" <wangsh(dot)fnst(at)fujitsu(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "Greg Sabino Mullane" <htamfids(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: make MaxBackends available in _PG_init |
| Date: | 2022-01-07 20:20:02 |
| Message-ID: | 7FDD160A-4E31-45CE-8B6F-8FE508E324F7@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/7/22, 10:12 AM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> While that approach would provide a way to safely retrieve the value,
> I think it would do little to prevent the issue in practice. If the
> size of the patch is a concern, we could also convert MaxBackends into
> a macro for calling GetMaxBackends(). This could also be a nice way
> to avoid breaking extensions that are using it correctly while
> triggering ERRORs for extensions that are using it incorrectly. I've
> attached a new version of the patch that does it this way.
v5 didn't work with EXEC_BACKEND. Here is a new revision.
Nathan
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-Disallow-external-access-to-MaxBackends.patch | application/octet-stream | 7.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bossart, Nathan | 2022-01-07 20:20:31 | Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux? |
| Previous Message | Jeff Davis | 2022-01-07 19:50:28 | Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers |