Make the Scanner module more flexible by allowing optional control
over when the scanned relation is opened and closed. Relations can
then remain open over multiple scans, which can improve performance
and efficiency.
Closes#2173
Rework debug waitpoint functionality to produce an error in
case if the waitpoint is enabled.
This update introduce a controlled way to simulate errors
scenarios during testing.
Time types, like date and timestamps, have limits that aren't the same
as the underlying storage type. For instance, while a timestamp is
stored as an `int64` internally, its max supported time value is not
`INT64_MAX`. Instead, `INT64_MAX` represents `+Infinity` and the
actual largest possible timestamp is close to `INT64_MAX` (but not
`INT64_MAX-1` either). The same applies to min values.
Unfortunately, time handling code does not check for these boundaries;
in most cases, overflow handling when, e.g., bucketing, are checked
against the max integer values instead of type-specific boundaries. In
other cases, overflows simply throw errors instead of clamping to the
boundary values, which makes more sense in many situations.
Using integer time suffers from similar issues. To take one example,
simply inserting a valid `smallint` value close to the max into a
table with a `smallint` time column fails:
```
INSERT INTO smallint_table VALUES ('32765', 1, 2.0);
ERROR: value "32770" is out of range for type smallint
```
This happens because the code that adds dimensional constraints always
checks for overflow against `INT64_MAX` instead of the type-specific
max value. Therefore, it tries to create a chunk constraint that ends
at `32770`, which is outside the allowed range of `smallint`.
The resolve these issues, several time-related utility functions have
been implemented that, e.g., return type-specific range boundaries,
and perform saturated addition and subtraction while clamping to
supported boundaries.
Fixes#2292
Test code in C should use test-specific assertions that throw errors
instead of exiting the program with a signal (crash). Not only does
this provide more useful and easily accessible information of the
failing condition, but it also allows running the test suite without
assertions (`USE_ASSERT_CHECKING`) enabled. Having assertions disabled
during tests also provides more accurate test coverage numbers. Note
that these test-specific assertions are not intended to replace
regular assertions (`Assert`), which are used in non-test code.
The way to enable (or disable) assertions in CMake has also been
simplified and cleaned up. The option `-DASSERTIONS=[ON|OFF]` can be
used to enable assertions for a build, unless already enabled in the
PostgreSQL one is building against (in which case that setting takes
precedence). Note that the `ASSERTIONS` option defaults to `OFF` since
it is no longer necessary to have assertions enabled for tests.
