| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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-09 23:40:54 |
| Message-ID: | 20230409234054.GC949159@rfd.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 09, 2023 at 02:45:16PM -0700, Andres Freund wrote:
> On 2023-04-08 21:29:54 -0700, Noah Misch wrote:
> > On Sat, Apr 08, 2023 at 11:08:16AM -0700, Andres Freund wrote:
> > > On 2023-04-07 23:04:08 -0700, Andres Freund wrote:
> > > > If you look at log_newpage_range(), it's not surprising that we get this error
> > > > - it pins up to 32 buffers at once.
> > > >
> > > > Afaics log_newpage_range() originates in 9155580fd5fc, but this caller is from
> > > > c6b92041d385.
> >
> > > > Do we care about fixing this in the backbranches? Probably not, given there
> > > > haven't been user complaints?
> >
> > I would not. This is only going to come up where the user goes out of the way
> > to use near-minimum shared_buffers.
>
> 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2023-04-09 23:46:16 | Re: Direct I/O |
| Previous Message | Michael Paquier | 2023-04-09 23:33:30 | Re: Parallel Full Hash Join |