2017-01-30 17:15:42 -05:00
|
|
|
--
|
|
|
|
|
-- Test assorted system views
|
|
|
|
|
--
|
|
|
|
|
-- This test is mainly meant to provide some code coverage for the
|
|
|
|
|
-- set-returning functions that underlie certain system views.
|
|
|
|
|
-- The output of most of these functions is very environment-dependent,
|
|
|
|
|
-- so our ability to test with fixed expected output is pretty limited;
|
|
|
|
|
-- but even a trivial check of count(*) will exercise the normal code path
|
|
|
|
|
-- through the SRF.
|
|
|
|
|
|
|
|
|
|
select count(*) >= 0 as ok from pg_available_extension_versions;
|
|
|
|
|
|
|
|
|
|
select count(*) >= 0 as ok from pg_available_extensions;
|
|
|
|
|
|
2020-08-25 21:52:02 -04:00
|
|
|
-- The entire output of pg_backend_memory_contexts is not stable,
|
2022-01-24 19:40:04 -05:00
|
|
|
-- we test only the existence and basic condition of TopMemoryContext.
|
2024-08-11 23:42:16 -04:00
|
|
|
select type, name, ident, level, total_bytes >= free_bytes
|
2024-07-24 23:03:28 -04:00
|
|
|
from pg_backend_memory_contexts where level = 1;
|
2020-08-25 21:52:02 -04:00
|
|
|
|
2024-04-16 00:21:31 -04:00
|
|
|
-- We can exercise some MemoryContext type stats functions. Most of the
|
2026-01-10 18:16:46 -05:00
|
|
|
-- column values are too platform-dependent to display.
|
2024-04-16 00:21:31 -04:00
|
|
|
|
|
|
|
|
-- Ensure stats from the bump allocator look sane. Bump isn't a commonly
|
|
|
|
|
-- used context, but it is used in tuplesort.c, so open a cursor to keep
|
|
|
|
|
-- the tuplesort alive long enough for us to query the context stats.
|
|
|
|
|
begin;
|
|
|
|
|
declare cur cursor for select left(a,10), b
|
|
|
|
|
from (values(repeat('a', 512 * 1024),1),(repeat('b', 512),2)) v(a,b)
|
|
|
|
|
order by v.a desc;
|
|
|
|
|
fetch 1 from cur;
|
2024-08-11 23:42:16 -04:00
|
|
|
select type, name, total_bytes > 0, total_nblocks, free_bytes > 0, free_chunks
|
2024-04-16 00:21:31 -04:00
|
|
|
from pg_backend_memory_contexts where name = 'Caller tuples';
|
|
|
|
|
rollback;
|
|
|
|
|
|
2024-07-24 23:03:28 -04:00
|
|
|
-- Further sanity checks on pg_backend_memory_contexts. We expect
|
|
|
|
|
-- CacheMemoryContext to have multiple children. Ensure that's the case.
|
|
|
|
|
with contexts as (
|
|
|
|
|
select * from pg_backend_memory_contexts
|
|
|
|
|
)
|
|
|
|
|
select count(*) > 1
|
|
|
|
|
from contexts c1, contexts c2
|
|
|
|
|
where c2.name = 'CacheMemoryContext'
|
|
|
|
|
and c1.path[c2.level] = c2.path[c2.level];
|
|
|
|
|
|
2017-01-30 17:15:42 -05:00
|
|
|
-- At introduction, pg_config had 23 entries; it may grow
|
|
|
|
|
select count(*) > 20 as ok from pg_config;
|
|
|
|
|
|
|
|
|
|
-- We expect no cursors in this test; see also portals.sql
|
|
|
|
|
select count(*) = 0 as ok from pg_cursors;
|
|
|
|
|
|
|
|
|
|
select count(*) >= 0 as ok from pg_file_settings;
|
|
|
|
|
|
2022-03-28 20:06:51 -04:00
|
|
|
-- There will surely be at least one rule, with no errors.
|
|
|
|
|
select count(*) > 0 as ok, count(*) FILTER (WHERE error IS NOT NULL) = 0 AS no_err
|
|
|
|
|
from pg_hba_file_rules;
|
2017-01-30 18:00:26 -05:00
|
|
|
|
2022-03-28 21:15:48 -04:00
|
|
|
-- There may be no rules, and there should be no errors.
|
|
|
|
|
select count(*) >= 0 as ok, count(*) FILTER (WHERE error IS NOT NULL) = 0 AS no_err
|
|
|
|
|
from pg_ident_file_mappings;
|
|
|
|
|
|
2017-01-30 17:15:42 -05:00
|
|
|
-- There will surely be at least one active lock
|
|
|
|
|
select count(*) > 0 as ok from pg_locks;
|
|
|
|
|
|
|
|
|
|
-- We expect no prepared statements in this test; see also prepare.sql
|
|
|
|
|
select count(*) = 0 as ok from pg_prepared_statements;
|
|
|
|
|
|
|
|
|
|
-- See also prepared_xacts.sql
|
|
|
|
|
select count(*) >= 0 as ok from pg_prepared_xacts;
|
|
|
|
|
|
2021-11-12 07:49:21 -05:00
|
|
|
-- There will surely be at least one SLRU cache
|
|
|
|
|
select count(*) > 0 as ok from pg_stat_slru;
|
|
|
|
|
|
2020-10-01 21:17:11 -04:00
|
|
|
-- There must be only one record
|
|
|
|
|
select count(*) = 1 as ok from pg_stat_wal;
|
|
|
|
|
|
2021-02-18 09:22:23 -05:00
|
|
|
-- We expect no walreceiver running in this test
|
|
|
|
|
select count(*) = 0 as ok from pg_stat_wal_receiver;
|
|
|
|
|
|
2026-03-05 22:37:40 -05:00
|
|
|
-- We expect no recovery state in this test (running on primary)
|
|
|
|
|
select count(*) = 0 as ok from pg_stat_recovery;
|
|
|
|
|
|
2017-01-30 17:15:42 -05:00
|
|
|
-- This is to record the prevailing planner enable_foo settings during
|
|
|
|
|
-- a regression test run.
|
|
|
|
|
select name, setting from pg_settings where name like 'enable%';
|
|
|
|
|
|
2024-06-27 22:21:05 -04:00
|
|
|
-- There are always wait event descriptions for various types. InjectionPoint
|
|
|
|
|
-- may be present or absent, depending on history since last postmaster start.
|
Add system view pg_wait_events
This new view, wrapped around a SRF, shows some information known about
wait events, as of:
- Name.
- Type (Activity, I/O, Extension, etc.).
- Description.
All the information retrieved comes from wait_event_names.txt, and the
description is the same as the documentation with filters applied to
remove any XML markups. This view is useful when joined with
pg_stat_activity to get the description of a wait event reported.
Custom wait events for extensions are included in the view.
Original idea by Yves Colin.
Author: Bertrand Drouvot
Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael
Paquier
Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 02:35:02 -04:00
|
|
|
select type, count(*) > 0 as ok FROM pg_wait_events
|
2024-06-27 22:21:05 -04:00
|
|
|
where type <> 'InjectionPoint' group by type order by type COLLATE "C";
|
Add system view pg_wait_events
This new view, wrapped around a SRF, shows some information known about
wait events, as of:
- Name.
- Type (Activity, I/O, Extension, etc.).
- Description.
All the information retrieved comes from wait_event_names.txt, and the
description is the same as the documentation with filters applied to
remove any XML markups. This view is useful when joined with
pg_stat_activity to get the description of a wait event reported.
Custom wait events for extensions are included in the view.
Original idea by Yves Colin.
Author: Bertrand Drouvot
Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael
Paquier
Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 02:35:02 -04:00
|
|
|
|
2017-01-30 17:15:42 -05:00
|
|
|
-- Test that the pg_timezone_names and pg_timezone_abbrevs views are
|
|
|
|
|
-- more-or-less working. We can't test their contents in any great detail
|
|
|
|
|
-- without the outputs changing anytime IANA updates the underlying data,
|
|
|
|
|
-- but it seems reasonable to expect at least one entry per major meridian.
|
|
|
|
|
-- (At the time of writing, the actual counts are around 38 because of
|
|
|
|
|
-- zones using fractional GMT offsets, so this is a pretty loose test.)
|
|
|
|
|
select count(distinct utc_offset) >= 24 as ok from pg_timezone_names;
|
|
|
|
|
select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
|
|
|
|
|
-- Let's check the non-default timezone abbreviation sets, too
|
|
|
|
|
set timezone_abbreviations = 'Australia';
|
|
|
|
|
select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
|
|
|
|
|
set timezone_abbreviations = 'India';
|
|
|
|
|
select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
|
Seek zone abbreviations in the IANA data before timezone_abbreviations.
If a time zone abbreviation used in datetime input is defined in
the currently active timezone, use that definition in preference
to looking in the timezone_abbreviations list. That allows us to
correctly handle abbreviations that have different meanings in
different timezones. Also, it eliminates an inconsistency between
datetime input and datetime output: the non-ISO datestyles for
timestamptz have always printed abbreviations taken from the IANA
data, not from timezone_abbreviations. Before this fix, it was
possible to demonstrate cases where casting a timestamp to text
and back fails or changes the value significantly because of that
inconsistency.
While this change removes the ability to override the IANA data about
an abbreviation known in the current zone, it's not clear that there's
any real use-case for doing so. But it is clear that this makes life
a lot easier for dealing with abbreviations that have conflicts across
different time zones.
Also update the pg_timezone_abbrevs view to report abbreviations
that are recognized via the IANA data, and *not* report any
timezone_abbreviations entries that are thereby overridden.
Under the hood, there are now two SRFs, one that pulls the IANA
data and one that pulls timezone_abbreviations entries. They're
combined by logic in the view. This approach was useful for
debugging (since the functions can be called on their own).
While I don't intend to document the functions explicitly,
they might be useful to call directly.
Also improve DecodeTimezoneAbbrev's caching logic so that it can
cache zone abbreviations found in the IANA data. Without that,
this patch would have caused a noticeable degradation of the
runtime of timestamptz_in.
Per report from Aleksander Alekseev and additional investigation.
Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=CO5XFMF4dvTGH+skzB--jNhqSQu5g@mail.gmail.com
2025-01-16 14:11:19 -05:00
|
|
|
-- One specific case we can check without much fear of breakage
|
|
|
|
|
-- is the historical local-mean-time value used for America/Los_Angeles.
|
|
|
|
|
select * from pg_timezone_abbrevs where abbrev = 'LMT';
|