Re: Direct I/O
От | Noah Misch |
---|---|
Тема | Re: Direct I/O |
Дата | |
Msg-id | 20230409234054.GC949159@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: Direct I/O (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Direct I/O
|
Список | 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?
В списке pgsql-hackers по дате отправления: