Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu |
Дата | |
Msg-id | 201101260244.p0Q2ikn21048@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu
|
Список | pgsql-committers |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, but verify > > it is 8k as expected. > > -#define WRITE_SIZE (8 * 1024) /* 8k */ > +#if XLOG_BLCKSZ != 8 * 1024 /* 8k */ > +#error Unknown block size for test. > +#endif > > This seems like a pretty awful idea. Aren't you aware that XLOG_BLCKSZ > is settable from a configure option? You just broke the ability to > build the tree with a non-default configuration setting. > > If you aren't willing to deal with a variable value for the block size, > please revert this patch. The problem is that I have hard-coded 8k into various text strings and I didn't want to make that variable. How should it behave if they are using a non-8k wal buffer size? Should it still use 8k or not? I figured throwing an error would at least alert them to the mismatch. Good point on the build problem --- I had not thought of that. Throwing an error when running makes more sense, but let's figure out what it should do. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-committers по дате отправления: