Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
От | Robert Haas |
---|---|
Тема | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Дата | |
Msg-id | CA+TgmoaJqH_hBdY4hjNq=iRLpZfNg2fDKMStqQ7LZb12mA+pMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
|
Список | pgsql-hackers |
On Mon, Apr 4, 2022 at 10:20 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > The checkpointer never takes heavyweight locks, so the opportunity > > you're describing can't arise. > > <thinks harder> Hmm, oh, you probably meant the buffer interlocking > in SyncOneBuffer(). It's true that my most recent patch throws away > more requests than it could, by doing the level check at the end of > the loop over all buffers instead of adding some kind of > DropPendingWritebacks() in the barrier handler. I guess I could find > a way to improve that, basically checking the level more often instead > of at the end, but I don't know if it's worth it; we're still throwing > out an arbitrary percentage of writeback requests. Doesn't every backend have its own set of pending writebacks? BufferAlloc() calls ScheduleBufferTagForWriteback(&BackendWritebackContext, ...)? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: