The commit cdea343cc updated the gh_matrix_builder.py script but failed
to import PG_LATEST variable into the script thus breaking the CI.
Import that variable to fix the CI tests.
During the compression autovacuum use to be disabled for uncompressed
chunk and enable after decompression. This leads to postgres
maintainence issue. Let's not disable autovacuum for uncompressed
chunk anymore. Let postgres take care of the stats in its natural way.
Fixes#309
When run in a parallel group, the dist_move_chunk test can get into a
deadlock with another test running a 'DROP DATABASE' command. So, mark
it as a solo test to disallow it from running in a parallel group.
Closes#4972
The telemetry_stats testcase uses random() with seed(1) to generate the
column values on which the hypertable is partitioned. The Postgres commit
postgres/postgres@3804539e48 updates the random() implementation to use a
better algorithim causing the test to generate a different set of rows in
PG15. Due to this the test failed in PG15 as the distrubution stats of
the tuples have now changed. Fixed that by creating separate test
outputs for PG15 and other releases.
Fixes#5037
This commit enables PG15 in the following workflows:
- Regression Linux
- ABI test
- Memory tests
- Coverity
- SQLSmith
- Additional cron tests
Co-authored-by: Bharathy Satish <bharathy@timescale.com>
In remote_txn, testcases which kill remote processes on data nodes,
tend to rollback transactions and as part of the process, WARNINGS/ERROR
are reported to client. Client however reports WARNINGS/ERROR in different
order intermittently. This is an issue specific to psql utility. Placing
psql in gdb and trying to diagnise the problem does not reproduce the issue.
This patch fixes the tests by not reporting WARNINGS.
Fixes#4837
INSERT .. SELECT query containing distributed hypertables generates plan
with DataNodeCopy node which is not supported. Issue is in function
tsl_create_distributed_insert_path() where we decide if we should
generate DataNodeCopy or DataNodeDispatch node based on the kind of
query. In PG15 for INSERT .. SELECT query timescaledb planner generates
DataNodeCopy as rte->subquery is set to NULL. This is because of a commit
in PG15 where rte->subquery is set to NULL as part of a fix.
This patch checks if SELECT subquery has distributed hypertables or not
by looking into root->parse->jointree which represents subquery.
Fixes#4983
PG15 introduced a ProcSignalBarrier mechanism in drop database
implementation to force all backends to close the file handles for
dropped tables. The backend that is executing the drop database command
will emit a new process signal barrier and wait for other backends to
accept it. But the backend which is executing the delete_data_node
function will not be able to process the above mentioned signal as it
will be stuck waiting for the drop database query to return. Thus the
two backends end up waiting for each other causing a deadlock.
Fixed it by using the async API to execute the drop database command
from delete_data_node instead of the blocking remote_connection_cmdf_ok
call.
Fixes#4838
The dist_move_chunk causes the CI to hang when compiled and run with
PG15 as explained in #4972.
Also fixed schema permission issues in data_node and dist_param tests.
On PG15 CustomScan by default is not projection capable, thus wraps this
node in Result node. THis change in PG15 causes tests result files which
have EXPLAIN output to fail. This patch fixes the plan outputs.
Fixes#4833
On PG15 new flag CUSTOMPATH_SUPPORT_PROJECTION is introduced. This flag
tells if a planner node is projection capable or not. CustomScan created
in TimescaleDB by default is not projection capable, this causes CustomScan
node to be wrapped around Result node. Update query on a hypertable has
a logic which is based on assumption that "ModifyTable" plan nodes lefttree
should be CustomScan node. With PG15 this assumption is broken which causes
"ERROR: variable not found in subplan target list".
Fixes#4834
Version 15 pg_dump program does not log any messages with log level <
PG_LOG_WARNING to stdout. Whereas this check is not present in version
14, thus we see corresponding tests fail with missing log information.
This patch fixes by supressing those log information, so that the tests
pass on all versions of postgresql.
Fixes#4832
To avoid untrusted logged data to use `set-state` and `set-output`
workflow commands without the intention of the workflow author GitHub
have introduced a new set of environment files to manage state and
output.
This commit changes the existing uses of `set-output` to use the new
environment files instead.
See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
When TimescaleDB 2.9.0 compiled against PG15, many tests fail due to
permissions on default public schema not getting propagated to data
nodes, although connected user has required GRANTS on access nodes.
This patch fixes failing tests by explicitly granting required permissions
for connected user or role after data nodes are added.
Currently, the next start of a scheduled background job is
calculated by adding the `schedule_interval` to its finish
time. This does not allow scheduling jobs to execute at fixed
times, as the next execution is "shifted" by the job duration.
This commit introduces the option to execute a job on a fixed
schedule instead. Users are expected to provide an initial_start
parameter on which subsequent job executions are aligned. The next
start is calculated by computing the next time_bucket of the finish
time with initial_start origin.
An `initial_start` parameter is added to the compression, retention,
reorder and continuous aggregate `add_policy` signatures. By passing
that upon policy creation users indicate the policy will execute on
a fixed schedule, or drifting schedule if `initial_start` is not
provided.
To allow users to pick a drifting schedule when registering a UDA,
an additional parameter `fixed_schedule` is added to `add_job`
to allow users to specify the old behavior by setting it to false.
Additionally, an optional TEXT parameter, `timezone`, is added to both
add_job and add_policy signatures, to address the 1-hour shift in
execution time caused by DST switches. As internally the next start of
a fixed schedule job is calculated using time_bucket, the timezone
parameter allows using timezone-aware buckets to calculate
the next start.
This patch adds a new settings file for common github action settings.
Instead of repeating latest pg versions in every github workflow we
can read the settings from this central file.
