Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?
От | Michael Paquier |
---|---|
Тема | Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes? |
Дата | |
Msg-id | Y+3iHyKFDAxp7kwI@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?
|
Список | pgsql-hackers |
On Wed, Feb 15, 2023 at 01:00:00PM +0530, Bharath Rupireddy wrote: > The v3 patch reduces initialization of iovec array elements which is a > clear win when pg_pwrite_zeros is called for sizes less than BLCKSZ > many times (I assume this is what is needed for the relation extension > lock improvements feature). However, it increases the number of iovec > initialization with zerobuf for the cases when pg_pwrite_zeros is > called for sizes far greater than BLCKSZ (for instance, WAL file > initialization). It seems to me that v3 would do extra initializations only if pg_pwritev_with_retry() does *not* retry its writes, but that's not the case as it retries on a partial write as per its name. The number of iov buffers is stricly capped by remaining_size. FWIW, I find v3 proposed more elegant. > FWIW, I attached v4 patch, a simplified version of the v2 - it > initializes all the iovec array elements if the total blocks to be > written crosses lengthof(iovec array), otherwise it initializes only > the needed blocks. + static size_t zbuf_sz = BLCKSZ; In v4, what's the advantage of marking that as static? It could actually be dangerous if this is carelessly updated. Well, that's not the case, still.. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: