Removed the PG12 specific macros and all the now, dead code. Also updated
the testcases which had workarounds in place to make them compatible
with PG12.
The backport script for the PRs does not have the permission to backport
PRs which include workflow changes. So, these PRs are excluded from
being automatically backported.
Failed CI run:
https://github.com/timescale/timescaledb/actions/runs/5387338161/
jobs/9780701395
> refusing to allow a GitHub App to create or update workflow
> `.github/workflows/xxx.yaml` without `workflows` permission)
The CHANGELOG.MD file contains the sections features, bugfixes, and
thanks. This patch adjusts the script merge_changelogs.sh to produce
the sections in the same order.
The test was failing on first run by leaving a database behind as a
sideeffect.
Between two steps the extension was dropped; without a proper cleanup.
A non-existent sql function was called during cleanup.
This patch also removes the "debug mode" and every execution will leave
the logs/etc in the /tmp directory for further inspection.
Adds a simple check to ensure that the PR number is present at least once
in the added changelog file.
Also fixes an earlier PR which introduced a typo.
The changes in this commit
1. workflow action to check if the PR has its own changelog file in
".unreleased/" folder.
2. script to merge the individual changelog entries that can be copied
into the CHANGELOG.md file.
3. script to check the format of the lines in the change log file.
4. script to delete the individual changelogs, post release.
Our cost model should be self-consistent, and the relative values for
the remote tuple and startup costs should reflect their real cost,
relative to costs of other operations like CPU tuple cost.
For example, now remote costs are set even lower than the parallel tuple
and startup cost. Contrary to that, their real world cost is going to be
an order of magnitude higher or more, because parallel tuples are sent
through shared memory, and remote tuples are sent over the network.
Increasing these costs leads to query plan improvements, e.g. we start
to favor the GROUP BY pushdown in some cases.
Whenever we create a template sql file (*.sql.in) we should add the
respective .gitignore entry for the generated test files.
So added a CI check to check for missing gitignore entries for generated
test files.
In case of joins in the continuous aggregates, pass the required
structs to the new rte created. These values are required by the
planner to finally query the materialized view.
Fixes#5433
NameData is a fixed-size type of 64 bytes. Using strlcpy to copy data
into a NameData struct can cause problems because any data that follows
the initial null-terminated string will also be part of the data.
The upgrade and downgrade tests are running PostgreSQL in Docker
containers. The function 'wait_for_pg' is used to determine if
PostgreSQL is ready to accept connections. In contrast to the upgrade
tests, the downgrade tests use more relaxed timeout values. The upgrade
tests sometimes fail because PostgreSQL cannot accept connections within
the configured time range. This patch applies the more relaxed timeout
values also to the upgrade script.
Using `strlcpy` to copy variables holding PostgreSQL names can cause
issues since names are fixed-size types of length 64. This means that
any data that follows the initial null-terminated string will also be
part of the data.
Instead of using `const char*` for PostgreSQL names, use `NameData`
type for PostgreSQL names and use `namestrcpy` to copy them rather
than `strlcpy`.
A follow-up for the review comments in the previous PR.
1. Create one backport PR per one source PR, even with multiple commits.
1. Add a comment to the source PR if we fail to backport it for some
reason.
1. Find the latest release branch
1. For each commit in main and not in release branch (compared by
title), find the corresponding PR.
1. If the PR fixes an issue labeled "bug", and neither the PR nor the
issue are labeled "no-backport", cherry-pick the commits from the PR
onto the release branch, and create a PR with these changes.
This patch includes two changes to the PR handling workflow:
(1) It changes the trigger for the workflow to pull_request_target. So,
PRs can now also be assigned to reviewers if the PR is opened from
external sources.
(2) A workflow has been added that automatically assigns PRs to the
author.
Add 2.9.0 to update test scripts and adjust downgrade scripts for
2.9.0. Additionally adjust CHANGELOG to sync with the actual release
CHANGELOG and add PG15 to CI.
This patch contains two changes to the Sanitizer checks:
(1) All logfiles of the Sanitizer will be uploaded to the
CI database.
(2) The Sanitizer checks are executed on every PR.
Not specifying alpine version causes libssl version
to change, which in turn cause error in downgrade tests
as well as ABI tests.
This commit also fixes shellcheck failures.
Some failing windows tests are addd to ignore list.
Co-authored-by: Lakshmi Narayanan Sreethar <lakshmi@timescale.com>
Co-authored-by: Alexander Kuzmenkov <akuzmenkov@timescale.com>
Signed-off-by: Sachin <sachin@timescale.com>
The downgrade script has printed a message in which the same variable is
used for the upgrade and the downgrade version. This patch corrects the
output and uses the correct variables.
It changed the type of Var.varno from Index to int. I'm starting to
wonder if it was a good idea to enable this warning, but maybe we can
give it the last try.
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.
The only configuration we're missing is the newline for braces after
case labels. The rest of the differences looks like bugs/omissions of
the version 8 that we use now.
Require clang-format-14 in cmake and use it in the CI check. We can't
support versions earlier than 14 because they have some
formatting differences that can't be configured.
Recently we fixed a DDL error (#4739) after upgrading to 2.8.0 version
that surprisly the CI upgrade/dowgrade tests didn't complained during
the development of the feature (#4552).
Fixed it by adding an specific query in the `post.catalog.sql` script to
make sure we'll check all the constraints of our internal tables and
catalog.
To allow perltidy to be used from editors and IDEs, the perltidyrc file
is moved from `scripts/perltidyrc` to `.perltidyrc`. This will allow
editors and IDEs to quickly find the style file in the root of the
repository, where `perltidy` normally searches for the style file.
The workflow is then updated to use the new location, and the two
options `--backup-file-extension` and `--backup-and-modify-in-place`
are moved to the workflow file to allow editors and IDEs to use
whatever method they find useful to process the file.
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.
