Re: [HACKERS] pg_test_fsync performance

2012-02-15 Thread Magnus Hagander
On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us wrote:
 On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
 On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
  Bruce Momjian br...@momjian.us writes:
   On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
   +1, I was about to suggest the same thing.  Running any of these tests
   for a fixed number of iterations will result in drastic degradation of
   accuracy as soon as the machine's behavior changes noticeably from what
   you were expecting.  Run them for a fixed time period instead.  Or maybe
   do a few, then check elapsed time and estimate a number of iterations to
   use, if you're worried about the cost of doing gettimeofday after each
   write.
 
   Good idea, and it worked out very well.  I changed the -o loops
   parameter to -s seconds which calls alarm() after (default) 2 seconds,
   and then once the operation completes, computes a duration per
   operation.
 
  I was kind of wondering how portable alarm() is, and the answer
  according to the buildfarm is that it isn't.

 I'm using following simplistic alarm() implementation for win32:

   https://github.com/markokr/libusual/blob/master/usual/signal.c#L21

 this works with fake sigaction()/SIGALARM hack below - to remember
 function to call.

 Good enough for simple stats printing, and avoids win32-specific
 code spreading around.

 Wow, I wasn't even aware this compiled in Win32;  I thought it was
 ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
 work.  (Me wonders if the GoGrid Windows images have compilers.)

They don't, since most of the compilers people would ask for don't
allow that kind of redistribution.

Ping me on im if you need one preconfigured, though...

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-15 Thread Bruce Momjian
On Wed, Feb 15, 2012 at 09:54:04AM +0100, Magnus Hagander wrote:
 On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us wrote:
  On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
  On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
   Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing.  Running any of these tests
for a fixed number of iterations will result in drastic degradation of
accuracy as soon as the machine's behavior changes noticeably from 
what
you were expecting.  Run them for a fixed time period instead.  Or 
maybe
do a few, then check elapsed time and estimate a number of iterations 
to
use, if you're worried about the cost of doing gettimeofday after each
write.
  
Good idea, and it worked out very well.  I changed the -o loops
parameter to -s seconds which calls alarm() after (default) 2 seconds,
and then once the operation completes, computes a duration per
operation.
  
   I was kind of wondering how portable alarm() is, and the answer
   according to the buildfarm is that it isn't.
 
  I'm using following simplistic alarm() implementation for win32:
 
    https://github.com/markokr/libusual/blob/master/usual/signal.c#L21
 
  this works with fake sigaction()/SIGALARM hack below - to remember
  function to call.
 
  Good enough for simple stats printing, and avoids win32-specific
  code spreading around.
 
  Wow, I wasn't even aware this compiled in Win32;  I thought it was
  ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
  work.  (Me wonders if the GoGrid Windows images have compilers.)
 
 They don't, since most of the compilers people would ask for don't
 allow that kind of redistribution.

Shame.

 Ping me on im if you need one preconfigured, though...

How do you do that?  Also, once you create a Windows VM on a public
cloud, how do you connect to it?  SSH?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-15 Thread Bruce Momjian
On Tue, Feb 14, 2012 at 08:23:10PM -0500, Bruce Momjian wrote:
 On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
  On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
   Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing.  Running any of these tests
for a fixed number of iterations will result in drastic degradation of
accuracy as soon as the machine's behavior changes noticeably from what
you were expecting.  Run them for a fixed time period instead.  Or 
maybe
do a few, then check elapsed time and estimate a number of iterations 
to
use, if you're worried about the cost of doing gettimeofday after each
write.
   
Good idea, and it worked out very well.  I changed the -o loops
parameter to -s seconds which calls alarm() after (default) 2 seconds,
and then once the operation completes, computes a duration per
operation.
   
   I was kind of wondering how portable alarm() is, and the answer
   according to the buildfarm is that it isn't.
  
  I'm using following simplistic alarm() implementation for win32:
  
https://github.com/markokr/libusual/blob/master/usual/signal.c#L21
  
  this works with fake sigaction()/SIGALARM hack below - to remember
  function to call.
  
  Good enough for simple stats printing, and avoids win32-specific
  code spreading around.
 
 Wow, I wasn't even aware this compiled in Win32;  I thought it was
 ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
 work.  (Me wonders if the GoGrid Windows images have compilers.)
 
 I see backend/port/win32/timer.c so I might go with a simple create a
 thread, sleep(2), set flag, exit solution.

Yeah, two Windows buildfarm machines have now successfully compiled my
patches, so I guess I fixed it;  patch attached.

The fix was surprisingly easy given the use of threads;  scheduling the
timeout in the operating system was just too invasive.

I would like to eventually know if this fix actually produces the right
output.  How would I test that?  Are the buildfarm output binaries
available somewhere?  Should I add this as a 9.2 TODO item?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/contrib/pg_test_fsync/pg_test_fsync.c b/contrib/pg_test_fsync/pg_test_fsync.c
new file mode 100644
index 02a9e21..7f92bc8
*** a/contrib/pg_test_fsync/pg_test_fsync.c
--- b/contrib/pg_test_fsync/pg_test_fsync.c
***
*** 28,39 
--- 28,54 
  #define OPS_FORMAT			%9.3f ops/sec
  
  /* These are macros to avoid timing the function call overhead. */
+ #ifndef WIN32
  #define START_TIMER	\
  do { \
  	alarm_triggered = false; \
  	alarm(secs_per_test); \
  	gettimeofday(start_t, NULL); \
  } while (0)
+ #else
+ /* WIN32 doesn't support alarm, so we create a thread and sleep there */
+ #define START_TIMER	\
+ do { \
+ 	alarm_triggered = false; \
+ 	if (CreateThread(NULL, 0, process_alarm, NULL, 0, NULL) == \
+ 		INVALID_HANDLE_VALUE) \
+ 	{ \
+ 		fprintf(stderr, Cannot create thread for alarm\n); \
+ 		exit(1); \
+ 	} \
+ 	gettimeofday(start_t, NULL); \
+ } while (0)
+ #endif
  
  #define STOP_TIMER	\
  do { \
*** static void test_sync(int writes_per_op)
*** 62,68 
--- 77,87 
  static void test_open_syncs(void);
  static void test_open_sync(const char *msg, int writes_size);
  static void test_file_descriptor_sync(void);
+ #ifndef WIN32
  static void process_alarm(int sig);
+ #else
+ static DWORD WINAPI process_alarm(LPVOID param);
+ #endif
  static void signal_cleanup(int sig);
  
  #ifdef HAVE_FSYNC_WRITETHROUGH
*** main(int argc, char *argv[])
*** 82,88 
--- 101,109 
  	/* Prevent leaving behind the test file */
  	signal(SIGINT, signal_cleanup);
  	signal(SIGTERM, signal_cleanup);
+ #ifndef WIN32
  	signal(SIGALRM, process_alarm);
+ #endif
  #ifdef SIGHUP
  	/* Not defined on win32 */
  	signal(SIGHUP, signal_cleanup);
*** print_elapse(struct timeval start_t, str
*** 550,560 
--- 571,592 
  	printf(OPS_FORMAT \n, per_second);
  }
  
+ #ifndef WIN32
  static void
  process_alarm(int sig)
  {
  	alarm_triggered = true;
  }
+ #else
+ static DWORD WINAPI
+ process_alarm(LPVOID param)
+ {
+ 	/* WIN32 doesn't support alarm, so we create a thread and sleep here */
+ 	Sleep(secs_per_test * 1000);
+ 	alarm_triggered = true;
+ 	ExitThread(0);
+ }
+ #endif
  
  static void
  die(const char *str)

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-15 Thread Magnus Hagander
On Wed, Feb 15, 2012 at 16:14, Bruce Momjian br...@momjian.us wrote:
 On Wed, Feb 15, 2012 at 09:54:04AM +0100, Magnus Hagander wrote:
 On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us wrote:
  On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
  On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
   Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing.  Running any of these 
tests
for a fixed number of iterations will result in drastic degradation 
of
accuracy as soon as the machine's behavior changes noticeably from 
what
you were expecting.  Run them for a fixed time period instead.  Or 
maybe
do a few, then check elapsed time and estimate a number of 
iterations to
use, if you're worried about the cost of doing gettimeofday after 
each
write.
  
Good idea, and it worked out very well.  I changed the -o loops
parameter to -s seconds which calls alarm() after (default) 2 seconds,
and then once the operation completes, computes a duration per
operation.
  
   I was kind of wondering how portable alarm() is, and the answer
   according to the buildfarm is that it isn't.
 
  I'm using following simplistic alarm() implementation for win32:
 
    https://github.com/markokr/libusual/blob/master/usual/signal.c#L21
 
  this works with fake sigaction()/SIGALARM hack below - to remember
  function to call.
 
  Good enough for simple stats printing, and avoids win32-specific
  code spreading around.
 
  Wow, I wasn't even aware this compiled in Win32;  I thought it was
  ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
  work.  (Me wonders if the GoGrid Windows images have compilers.)

 They don't, since most of the compilers people would ask for don't
 allow that kind of redistribution.

 Shame.

 Ping me on im if you need one preconfigured, though...

 How do you do that?  Also, once you create a Windows VM on a public
 cloud, how do you connect to it?  SSH?

rdesktop.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-14 Thread Bruce Momjian
On Mon, Feb 13, 2012 at 09:54:06PM -0500, Bruce Momjian wrote:
 On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
  Robert Haas robertmh...@gmail.com writes:
   Instead of or in addition to a fixed number operations per test, maybe
   we should cut off each test after a certain amount of wall-clock time,
   like 15 seconds.
  
  +1, I was about to suggest the same thing.  Running any of these tests
  for a fixed number of iterations will result in drastic degradation of
  accuracy as soon as the machine's behavior changes noticeably from what
  you were expecting.  Run them for a fixed time period instead.  Or maybe
  do a few, then check elapsed time and estimate a number of iterations to
  use, if you're worried about the cost of doing gettimeofday after each
  write.
 
 Good idea, and it worked out very well.  I changed the -o loops
 parameter to -s seconds which calls alarm() after (default) 2 seconds,
 and then once the operation completes, computes a duration per
 operation.

Update patch applied, with additional fix for usage message, and use of
macros for start/stop testing.

I like this method much better because not only does it speed up the
test, but it also allows the write test, which completes very quickly,
to run longer and report more accurate numbers.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-14 Thread Tom Lane
Bruce Momjian br...@momjian.us writes:
 On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
 +1, I was about to suggest the same thing.  Running any of these tests
 for a fixed number of iterations will result in drastic degradation of
 accuracy as soon as the machine's behavior changes noticeably from what
 you were expecting.  Run them for a fixed time period instead.  Or maybe
 do a few, then check elapsed time and estimate a number of iterations to
 use, if you're worried about the cost of doing gettimeofday after each
 write.

 Good idea, and it worked out very well.  I changed the -o loops
 parameter to -s seconds which calls alarm() after (default) 2 seconds,
 and then once the operation completes, computes a duration per
 operation.

I was kind of wondering how portable alarm() is, and the answer
according to the buildfarm is that it isn't.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-14 Thread Marko Kreen
On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
  +1, I was about to suggest the same thing.  Running any of these tests
  for a fixed number of iterations will result in drastic degradation of
  accuracy as soon as the machine's behavior changes noticeably from what
  you were expecting.  Run them for a fixed time period instead.  Or maybe
  do a few, then check elapsed time and estimate a number of iterations to
  use, if you're worried about the cost of doing gettimeofday after each
  write.
 
  Good idea, and it worked out very well.  I changed the -o loops
  parameter to -s seconds which calls alarm() after (default) 2 seconds,
  and then once the operation completes, computes a duration per
  operation.
 
 I was kind of wondering how portable alarm() is, and the answer
 according to the buildfarm is that it isn't.

I'm using following simplistic alarm() implementation for win32:

  https://github.com/markokr/libusual/blob/master/usual/signal.c#L21

this works with fake sigaction()/SIGALARM hack below - to remember
function to call.

Good enough for simple stats printing, and avoids win32-specific
code spreading around.

-- 
marko


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-14 Thread Bruce Momjian
On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
 On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
  Bruce Momjian br...@momjian.us writes:
   On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
   +1, I was about to suggest the same thing.  Running any of these tests
   for a fixed number of iterations will result in drastic degradation of
   accuracy as soon as the machine's behavior changes noticeably from what
   you were expecting.  Run them for a fixed time period instead.  Or maybe
   do a few, then check elapsed time and estimate a number of iterations to
   use, if you're worried about the cost of doing gettimeofday after each
   write.
  
   Good idea, and it worked out very well.  I changed the -o loops
   parameter to -s seconds which calls alarm() after (default) 2 seconds,
   and then once the operation completes, computes a duration per
   operation.
  
  I was kind of wondering how portable alarm() is, and the answer
  according to the buildfarm is that it isn't.
 
 I'm using following simplistic alarm() implementation for win32:
 
   https://github.com/markokr/libusual/blob/master/usual/signal.c#L21
 
 this works with fake sigaction()/SIGALARM hack below - to remember
 function to call.
 
 Good enough for simple stats printing, and avoids win32-specific
 code spreading around.

Wow, I wasn't even aware this compiled in Win32;  I thought it was
ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
work.  (Me wonders if the GoGrid Windows images have compilers.)

I see backend/port/win32/timer.c so I might go with a simple create a
thread, sleep(2), set flag, exit solution.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-13 Thread Robert Haas
On Mon, Feb 13, 2012 at 7:42 PM, Bruce Momjian br...@momjian.us wrote:
 I have heard complaints that /contrib/pg_test_fsync is too slow.  I
 thought it was impossible to speed up pg_test_fsync without reducing its
 accuracy.

 However, now that I some consumer-grade SATA 2 drives, I noticed that
 the slowness is really in the open_sync test:

        Compare open_sync with different write sizes:
        (This is designed to compare the cost of writing 16kB
        in different write open_sync sizes.)
                 1 * 16kB open_sync write          76.421 ops/sec
                 2 *  8kB open_sync writes         38.689 ops/sec
                 4 *  4kB open_sync writes         19.140 ops/sec
                 8 *  2kB open_sync writes          4.938 ops/sec
                16 *  1kB open_sync writes          2.480 ops/sec

 These last few lines can take very long, so I developed the attached
 patch that scales down the number of tests.  This makes it more
 reasonable to run pg_test_fsync.

 I would like to apply this for PG 9.2.

On my MacOS X, it's fsync_writethrough that's insanely slow:

[rhaas pg_test_fsync]$ ./pg_test_fsync
2000 operations per test
Direct I/O is not supported on this platform.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync3523.267 ops/sec
fdatasync3360.023 ops/sec
fsync2410.048 ops/sec
fsync_writethrough 12.576 ops/sec
open_sync3649.475 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync1885.284 ops/sec
fdatasync2544.652 ops/sec
fsync3241.218 ops/sec
fsync_writethrough  ^C

Instead of or in addition to a fixed number operations per test, maybe
we should cut off each test after a certain amount of wall-clock time,
like 15 seconds.  It's kind of insane to run one of these tests for 3
minutes.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 Instead of or in addition to a fixed number operations per test, maybe
 we should cut off each test after a certain amount of wall-clock time,
 like 15 seconds.

+1, I was about to suggest the same thing.  Running any of these tests
for a fixed number of iterations will result in drastic degradation of
accuracy as soon as the machine's behavior changes noticeably from what
you were expecting.  Run them for a fixed time period instead.  Or maybe
do a few, then check elapsed time and estimate a number of iterations to
use, if you're worried about the cost of doing gettimeofday after each
write.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_test_fsync performance

2012-02-13 Thread Bruce Momjian
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  Instead of or in addition to a fixed number operations per test, maybe
  we should cut off each test after a certain amount of wall-clock time,
  like 15 seconds.
 
 +1, I was about to suggest the same thing.  Running any of these tests
 for a fixed number of iterations will result in drastic degradation of
 accuracy as soon as the machine's behavior changes noticeably from what
 you were expecting.  Run them for a fixed time period instead.  Or maybe
 do a few, then check elapsed time and estimate a number of iterations to
 use, if you're worried about the cost of doing gettimeofday after each
 write.

Good idea, and it worked out very well.  I changed the -o loops
parameter to -s seconds which calls alarm() after (default) 2 seconds,
and then once the operation completes, computes a duration per
operation.

The test now runs in 30 seconds and produces similar output to the
longer version.
 
-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/contrib/pg_test_fsync/pg_test_fsync.c b/contrib/pg_test_fsync/pg_test_fsync.c
new file mode 100644
index 3fcb087..8554426
*** a/contrib/pg_test_fsync/pg_test_fsync.c
--- b/contrib/pg_test_fsync/pg_test_fsync.c
***
*** 27,41 
  #define NA_FORMAT			%18s
  #define OPS_FORMAT			%9.3f ops/sec
  
  static const char *progname;
  
! static int	ops_per_test = 2000;
  static int	needs_unlink = 0;
  static char full_buf[XLOG_SEG_SIZE],
  		   *buf,
  		   *filename = FSYNC_FILENAME;
  static struct timeval start_t,
  			stop_t;
  
  
  static void handle_args(int argc, char *argv[]);
--- 27,50 
  #define NA_FORMAT			%18s
  #define OPS_FORMAT			%9.3f ops/sec
  
+ #define START_TIMER	\
+ do { \
+ 	alarm_triggered = false; \
+ 	alarm(secs_per_test); \
+ 	gettimeofday(start_t, NULL); \
+ } while (0)
+ 
+ 
  static const char *progname;
  
! static int	secs_per_test = 2;
  static int	needs_unlink = 0;
  static char full_buf[XLOG_SEG_SIZE],
  		   *buf,
  		   *filename = FSYNC_FILENAME;
  static struct timeval start_t,
  			stop_t;
+ static bool alarm_triggered = false;
  
  
  static void handle_args(int argc, char *argv[]);
*** static void test_sync(int writes_per_op)
*** 46,57 
  static void test_open_syncs(void);
  static void test_open_sync(const char *msg, int writes_size);
  static void test_file_descriptor_sync(void);
  static void signal_cleanup(int sig);
  
  #ifdef HAVE_FSYNC_WRITETHROUGH
  static int	pg_fsync_writethrough(int fd);
  #endif
! static void print_elapse(struct timeval start_t, struct timeval stop_t);
  static void die(const char *str);
  
  
--- 55,67 
  static void test_open_syncs(void);
  static void test_open_sync(const char *msg, int writes_size);
  static void test_file_descriptor_sync(void);
+ static void process_alarm(int sig);
  static void signal_cleanup(int sig);
  
  #ifdef HAVE_FSYNC_WRITETHROUGH
  static int	pg_fsync_writethrough(int fd);
  #endif
! static void print_elapse(struct timeval start_t, struct timeval stop_t, int ops);
  static void die(const char *str);
  
  
*** main(int argc, char *argv[])
*** 65,70 
--- 75,81 
  	/* Prevent leaving behind the test file */
  	signal(SIGINT, signal_cleanup);
  	signal(SIGTERM, signal_cleanup);
+ 	signal(SIGALRM, process_alarm);
  #ifdef SIGHUP
  	/* Not defined on win32 */
  	signal(SIGHUP, signal_cleanup);
*** handle_args(int argc, char *argv[])
*** 96,102 
  {
  	static struct option long_options[] = {
  		{filename, required_argument, NULL, 'f'},
! 		{ops-per-test, required_argument, NULL, 'o'},
  		{NULL, 0, NULL, 0}
  	};
  	int			option;			/* Command line option */
--- 107,113 
  {
  	static struct option long_options[] = {
  		{filename, required_argument, NULL, 'f'},
! 		{secs-per-test, required_argument, NULL, 's'},
  		{NULL, 0, NULL, 0}
  	};
  	int			option;			/* Command line option */
*** handle_args(int argc, char *argv[])
*** 117,123 
  		}
  	}
  
! 	while ((option = getopt_long(argc, argv, f:o:,
   long_options, optindex)) != -1)
  	{
  		switch (option)
--- 128,134 
  		}
  	}
  
! 	while ((option = getopt_long(argc, argv, f:s:,
   long_options, optindex)) != -1)
  	{
  		switch (option)
*** handle_args(int argc, char *argv[])
*** 126,133 
  filename = strdup(optarg);
  break;
  
! 			case 'o':
! ops_per_test = atoi(optarg);
  break;
  
  			default:
--- 137,144 
  filename = strdup(optarg);
  break;
  
! 			case 's':
! secs_per_test = atoi(optarg);
  break;
  
  			default:
*** handle_args(int argc, char *argv[])
*** 148,154 
  		exit(1);
  	}
  
! 	printf(%d operations per test\n, ops_per_test);
  #if PG_O_DIRECT != 0
  	printf(O_DIRECT supported on this