Since the isolationtester got modified to improve the query result
output which got backported in to PG12 and PG13 we have to adjust
all isolationtester output.
https://github.com/postgres/postgres/commit/4a05406
Fix a number of issues with size and stats functions:
* Return `0` size instead of `NULL` in several functions when
hypertables have no chunks (e.g., `hypertable_size`,
`hypertable_detailed_size`).
* Return `NULL` when functions are called on non-hypertables instead
of simply failing with generic error `query returned no rows`.
* Include size of "root" hypertable, which can have non-zero size
indexes and other objects even if the root table holds no data.
* Make `hypertable_detailed_size` include one additional row for
storage size of objects on the access node. While the access node
stores no data, the empty hypertable may still take up some disk
space.
* Improve test coverage for all size utility functions. In particular,
add tests on regular tables as well as empty and compressed
hypertables.
* Several size utility functions that were defined as `PL/pgSQL`
functions have been converted to simple `SQL` functions since they
ran only a single SQL query.
The `dist_util` test is moved to the solo test group because,
otherwise, it gives different size output when run in parallel vs. in
isolation.
Fixes#2871
When executing `CREATE INDEX` with `transaction_per_chunk` one
transaction is created at the start to mark the index as invalid, a
session lock is taken to prevent competing `DROP INDEX` from modifying
the indexes, then each chunk is updated inside a separate transaction,
one transaction is created to mark the index as valid, and lastly the
session lock is released.
However, the last transaction was not committed and left open, so a
competing `DROP INDEX` would try to read index status after the session
lock was released, resulting in a concurrent access of the index row
from the `CREATE INDEX`.
This commit fixes that by committing the transaction before releasing
the session lock (and starting another transaction to match the
end-of-statement commit that is done later).
Fixes#3021
The flake in `multi_transaction_indexing` is because of a race between
`CREATE INDEX` and `DROP INDEX` and this commit add a debug waitpoint
so that we can reliably reproduce the race condition in the isolation
test.
This just addresses some minor test changes for PostgresQL version
12. Specifically it changes the tests to set client_min_message to
error, as fatal is no longer a valid setting here. This also hides
a new NOTICE message in bgw_job_delete, which was including a PID
and was thus nondeterministic.
Currently CREATE INDEX creates the indices for all chunks in a single
transaction, which holds a lock on the root hypertable and all chunks. This
means that during CREATE INDEX no new inserts can occur, even if we're not
currently building an index on the table being inserted to.
This commit adds the option to create indices using a separate
transaction for each chunk. This option, used like
CREATE INDEX ON <table> WITH (timescaledb.transaction_per_chunk);
should cause less contention than a regular CREATE INDEX, in exchange
for the possibility that the index will be created on only some, or none,
of the chunks, if the command fails partway through. The command holds a lock on
the root index used as a template throughout the command, and each of the only
additionally locks the chunk being indexed. This means that that chunks which
are not currently being indexed can be inserted to, and new chunks can be
created while the CREATE INDEX command is in progress.
To enable detection of failed transaction_per_chunk CREATE INDEXs, the
hypertable's index is marked as invalid while the CREATE INDEX is in progress,
if the command fails partway through, the index will remain invalid. If such an
invalid index is discovered, it can be dropped an recreated to ensure that all
chunks have a copy of the index, in the future, we may add a command to create
indexes on only those chunks which are missing them. Note that even though the
hypertable's index is marked as invalid, new chunks will have a copy of the
index build as normal.
As part of the refactoring to make this command work, normal index creation was
slightly modified. Instead of getting the column names an index uses
one-at-a-time we get them all at once at the beginning of index creation, this
allows to close the hypertable's root table once we've determined all of while
we create the index info for each chunk. Secondly, it changes our function to
lookup a tablespace, ts_hypertable_get_tablespace_at_offset_from, to only take a
hypertable id, instead of the hypertable's entire cache entry; this function
only ever used the id, so this allows us to release the hypertable cache earlier
