Thread

Avoiding a small risk of failure in timestamp(tz) regression tests

Tom Lane <tgl@sss.pgh.pa.us> — 2019-12-22T16:11:57Z

I noticed a buildfarm failure here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skate&dt=2019-12-22%2007%3A49%3A22

================== pgsql.build/src/test/regress/regression.diffs ==================
*** /home/pgbf/buildroot/REL_10_STABLE/pgsql.build/src/test/regress/expected/timestamptz.out	2019-12-13 08:51:47.000000000 +0100
--- /home/pgbf/buildroot/REL_10_STABLE/pgsql.build/src/test/regress/results/timestamptz.out	2019-12-22 09:00:00.000000000 +0100
***************
*** 27,33 ****
  SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'today';
   one 
  -----
!    1
  (1 row)
  
  SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';
--- 27,33 ----
  SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'today';
   one 
  -----
!    2
  (1 row)
  
  SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';


Judging by the reported timestamp on the results file, this is an instance
of the problem mentioned in the comments in timestamptz.sql:

-- NOTE: it is possible for this part of the test to fail if the transaction
-- block is entered exactly at local midnight; then 'now' and 'today' have
-- the same values and the counts will come out different.

On most machines it'd be pretty hard to hit that window; I speculate that
"skate" has got a very low-resolution system clock, making the window
larger.  Nonetheless, a test that's got designed-in failure modes is
annoying.  We can dodge this by separating the test for "now" from the
tests for the today/tomorrow/etc input strings, as attached.
Any objections?

			regards, tom lane