This moves the contents of the readme used for hashicorp/boundary on
docker.io/registry.hub.docker.com to a separate readme file from the one that
documents how to build docker images. It also makes some minor fixups
and updates the docker.io readme, must notably updating the minimum
version of postgres that boundary requires.
This provides a new storage.FS implementation that expands the on
fstest.MemFS by allowing tests to mark the filesystem as out of space.
When this happens any write/create operation will start returning an
error indicating that the filesystem is out of space.
fix(session): List performance with large number of session connections
This includes the backported migration and a migration to ensure the next
release has the correct view.
As part of the performance improvements for listing sessions for v0.9.0,
the view used to retrieve sessions for listing was updated to no longer
include a join on session_connection. However, a later migration that
was adding additional columns to this view inadvertently re-added the
join and session_connection columns. This resulted in requests to list
sessions performing this join, and returning additional rows for each
connection in a session. The application would ignore this additional
data, since it is no longer returned via the API. This would be
particularly impactful in cases where there are a large number of
connections per session, as this would greatly increase the amount of
data returned by the database.
This fix removes the session_connection join from this view, which
should restore the original performance improvements even in cases where
there is a large number of session connections per session.
See: https://github.com/hashicorp/boundary/pull/2160
Ref: 32070678dc
Fixes: 1e3c941be1
(cherry picked from commit 7aef341682e65b42c1b919e03936bdf81e26e87c)
As part of the performance improvements for listing sessions for v0.9.0,
the view used to retrieve sessions for listing was updated to no longer
include a join on session_connection. However, a later migration that
was adding additional columns to this view inadvertently re-added the
join and session_connection columns. This resulted in requests to list
sessions performing this join, and returning additional rows for each
connection in a session. The application would ignore this additional
data, since it is no longer returned via the API. This would be
particularly impactful in cases where there are a large number of
connections per session, as this would greatly increase the amount of
data returned by the database.
This fix removes the session_connection join from this view, which
should restore the original performance improvements even in cases where
there is a large number of session connections per session.
See: https://github.com/hashicorp/boundary/pull/2160
Ref: 32070678dc
Fixes: 1e3c941be1
This removes the minimum on width and height, instead it will just used
the largest width, height seen as the initial size for the asciicast.
This also provides the ability to still set a minimum via options to
convert.ToAsciicast if the caller has a known minimum size. Also note
that in cases where there is no size information, ie if there was no pty
request, this will still pick a default size of 80x24.
This adds the `update_sessions_pending_daily_snapshot` SQL function
which updates the `sessions_pending_daily_snapshot` table by inserting
values for any days missing from the table.
This also adds a check constraint to the
`sessions_pending_daily_snapshot` table along with a `comment on table`.
This also removes the hcp daily billing views since they are no longer
needed.
Ref: ace2def49d
The hcp monthly billing views build a range of buckets using the
`generate_series` and the `now()` functions along with relative offsets
like `+ 1 month`. The calculated start and end times for these views can
vary depending on the time zone setting of the PostgreSQL server.
This adds 3 table functions that call their respective views with the
time zone set to UTC. Calling these functions instead of their
underlying views directly prevents the returned values from varying when
the server's time zone is not set to UTC.
This also drops support for PostgreSQL 11. The included tests use the
`date_trunc(field, source [, time_zone ])` function added in PostgreSQL
12.
Fixes: 41b1b5b4b7
The hcp billing `_all` views built a range of buckets using the
`generate_series` function using the minimum value of the
`session_pending_time` column from the `wh_session_accumulating_fact`
table as the start time and `now()` as the end time. It then truncated
values in the series using the `date_trunc` function. This allowed the
generated series of buckets returned to vary and could result in one
additional bucket being included in the series depending on the current
time and the start time.
As an illustrative example, the `hourly_all` query used:
select date_trunc('hour',time)
from generate_series(
(select min(session_pending_time) -- start time
from wh_session_accumulating_fact),
now(),
'1 hour'::interval
) as time;
Substituting the start time with a hard coded value to show the issue:
-- Show current time, where the minutes portion is 55
select now();
now
-------------------------------
2023-05-22 14:55:40.567605+00
(1 row)
-- generate series with start time's minutes portion at 57
select date_trunc('hour',time)
from generate_series(
'2023-05-22 01:57:00'::timestamptz,
now(),
'1 hour'::interval
) as time;
date_trunc
------------------------
2023-05-22 01:00:00+00
2023-05-22 02:00:00+00
2023-05-22 03:00:00+00
2023-05-22 04:00:00+00
2023-05-22 05:00:00+00
2023-05-22 06:00:00+00
2023-05-22 07:00:00+00
2023-05-22 08:00:00+00
2023-05-22 09:00:00+00
2023-05-22 10:00:00+00
2023-05-22 11:00:00+00
2023-05-22 12:00:00+00
2023-05-22 13:00:00+00
(13 rows)
-- Wait a few minutes
select now();
now
------------------------------
2023-05-22 14:58:48.75287+00
(1 row)
-- Now run again and get an extra result, even though still
-- within the same hour
select date_trunc('hour',time)
from generate_series(
'2023-05-22 01:57:00'::timestamptz,
now(),
'1 hour'::interval
) as time;
date_trunc
------------------------
2023-05-22 01:00:00+00
2023-05-22 02:00:00+00
2023-05-22 03:00:00+00
2023-05-22 04:00:00+00
2023-05-22 05:00:00+00
2023-05-22 06:00:00+00
2023-05-22 07:00:00+00
2023-05-22 08:00:00+00
2023-05-22 09:00:00+00
2023-05-22 10:00:00+00
2023-05-22 11:00:00+00
2023-05-22 12:00:00+00
2023-05-22 13:00:00+00
2023-05-22 14:00:00+00
(14 rows)
To fix this, we call the `generate_series` function truncating the start
time argument to the bucket size:
-- Hourly
select bucket
from generate_series(
date_trunc('hour', select min(session_pending_time)
from wh_session_accumulating_fact)),
now(),
'1 hour'::interval
) as bucket;
-- Monthly
select bucket
from generate_series(
date_trunc('month', select min(session_pending_time)
from wh_session_accumulating_fact)),
now(),
'1 month'::interval
) as bucket;
Fixes: 41b1b5b4b7
Certain tests fail when run on the first day of the month because of
edge cases in the setup of test data. This adds conditional logic to
skip those tests when run on the first day of a month.
Michael Gaffney
Louis Ruch
Mark Collao
Cameron Perera
Timothy Messier
Dharini Jeeva
Michael Milton
Todd
Jim