Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu - Mailing list pgsql-committers

From Bruce Momjian
Subject Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu
Date
Msg-id 201101260244.p0Q2ikn21048@momjian.us
Whole thread Raw
In response to Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Use XLOG_BLCKSZ in pg_test_fsync, rather than our own define, bu