Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows
Дата
Msg-id 20200715065356.GC8389@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-bugs
On Tue, Jul 14, 2020 at 10:27:00AM -0400, Bruce Momjian wrote:
> OK.  I am kind of surprised we haven't received bug reports earlier, but
> I guess few Windows users run pg_test_fsync, and fewer report problems.

On 11 and older versions, we use O_TEXT with pg_test_fsync.  This does
not cause directly a failure, but those versions have as other problem
to not be able to handle properly O_DSYNC, leading to tests of
open_fdatasync to show extremely high and incorrect outputs:
https://www.postgresql.org/message-id/1527864509.2475.49.camel@cybertec.at
And it is the concurrent use of O_DSYNC with O_TEXT that's visibly
causing a problem for 12~.

O_DSYNC handling got addressed in v12 with 0ba06e0, and while changing
back branches for ~11 to allow frontends to use our concurrent-safe
version of fopen()/open() would be tempting, I don't think that fixing
one test of pg_test_fsync is a reason enough to potentially risk
breakages for other client tools inside, or even outside, the core
tree.

If there are no objections, I would like to just change the tool to
use the binary mode down to 9.5.  I can see that the text mode is
getting used for all branches, and that's wrong as the aim is to test
binary writes, basically as you said as well upthread.
--
Michael

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16542: High CPU Usage
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16543: Package conflicts due to missing llvm-toolset-7-clang >= 4.0.1 and proj70 >= 7.0.1