| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Direct I/O |
| Date: | 2023-04-11 17:53:35 |
| Message-ID: | 20230411175335.ku2wacyp3ef5pkmj@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-04-09 16:40:54 -0700, Noah Misch wrote:
> On Sun, Apr 09, 2023 at 02:45:16PM -0700, Andres Freund wrote:
> > It's not *just* that scenario. With a few concurrent connections you can get
> > into problematic territory even with halfway reasonable shared buffers.
>
> I am not familiar with such cases. You could get there with 64MB shared
> buffers and 256 simultaneous commits of new-refilenode-creating transactions,
> but I'd still file that under going out of one's way to use tiny shared
> buffers relative to the write activity. What combination did you envision?
I'd not say it's common, but it's less crazy than running with 128kB of s_b...
There's also the issue that log_newpage_range() is used in number of places
where we could have a lot of pre-existing buffer pins. So pinning another 64
buffers could tip us over.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-04-11 17:57:04 | Re: When to drop src/tools/msvc support |
| Previous Message | Andy Fan | 2023-04-11 17:45:10 | Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel |