Re: Attempt to consolidate reading of XLOG page
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Attempt to consolidate reading of XLOG page |
| Дата | |
| Msg-id | 20191118122903.GH1543@paquier.xyz обсуждение |
| Ответ на | Re: Attempt to consolidate reading of XLOG page (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: Attempt to consolidate reading of XLOG page
|
| Список | pgsql-hackers |
On Fri, Nov 15, 2019 at 06:41:02PM -0300, Alvaro Herrera wrote: > I don't quite understand why you backed off from switching to pread. It > seemed a good change to me. > > [...] > > Having seek/open be a boolean "xlr_seek" seems a bit weird. Changed to > an "operation" enum. (Maybe if we go back to pg_pread we can get rid of > this.) Accordingly, change WALReadRaiseError and WALDumpReadPage. This has been quickly mentioned on the thread which has introduced pread(): https://www.postgresql.org/message-id/c2f56d0a-cadd-3df1-ae48-b84dc8128c37@redhat.com Now, read() > pread() > read()+lseek(), and we don't actually need to seek into the file for all the cases where we read a WAL page. And on a platform which uses the fallback implementation, this increases the number of lseek() calls. I can see as you say that using it directly in the refactoring can simplify the code. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера