Improve test coverage in bump.c
There were no callers of BumpAllocLarge() in the regression tests, so here we add a sort with a tuple large enough to use that path in bump.c. Also, BumpStats() wasn't being called, so add a test to sysviews.sql to call pg_backend_memory_contexts() while a bump context exists in the backend. Reported-by: Andres Freund Discussion: https://postgr.es/m/20240414223305.m3i5eju6zylabvln@awork3.anarazel.de
This commit is contained in:
parent
768ceeeaa1
commit
bea97cd02e
|
@ -28,6 +28,29 @@ select name, ident, parent, level, total_bytes >= free_bytes
|
|||
TopMemoryContext | | | 0 | t
|
||||
(1 row)
|
||||
|
||||
-- We can exercise some MemoryContext type stats functions. Most of the
|
||||
-- column values are too platform-dependant to display.
|
||||
-- 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;
|
||||
left | b
|
||||
------------+---
|
||||
bbbbbbbbbb | 2
|
||||
(1 row)
|
||||
|
||||
select name, parent, total_bytes > 0, total_nblocks, free_bytes > 0, free_chunks
|
||||
from pg_backend_memory_contexts where name = 'Caller tuples';
|
||||
name | parent | ?column? | total_nblocks | ?column? | free_chunks
|
||||
---------------+----------------+----------+---------------+----------+-------------
|
||||
Caller tuples | TupleSort sort | t | 3 | t | 0
|
||||
(1 row)
|
||||
|
||||
rollback;
|
||||
-- At introduction, pg_config had 23 entries; it may grow
|
||||
select count(*) > 20 as ok from pg_config;
|
||||
ok
|
||||
|
|
|
@ -343,6 +343,19 @@ ORDER BY ctid DESC LIMIT 5;
|
|||
(5 rows)
|
||||
|
||||
ROLLBACK;
|
||||
----
|
||||
-- test sorting of large datums VALUES
|
||||
----
|
||||
-- Ensure the order is correct and values look intact
|
||||
SELECT LEFT(a,10),b FROM
|
||||
(VALUES(REPEAT('a', 512 * 1024),1),(REPEAT('b', 512 * 1024),2)) v(a,b)
|
||||
ORDER BY v.a DESC;
|
||||
left | b
|
||||
------------+---
|
||||
bbbbbbbbbb | 2
|
||||
aaaaaaaaaa | 1
|
||||
(2 rows)
|
||||
|
||||
----
|
||||
-- test forward and backward scans for in-memory and disk based tuplesort
|
||||
----
|
||||
|
|
|
@ -17,6 +17,21 @@ select count(*) >= 0 as ok from pg_available_extensions;
|
|||
select name, ident, parent, level, total_bytes >= free_bytes
|
||||
from pg_backend_memory_contexts where level = 0;
|
||||
|
||||
-- We can exercise some MemoryContext type stats functions. Most of the
|
||||
-- column values are too platform-dependant to display.
|
||||
|
||||
-- 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;
|
||||
select name, parent, total_bytes > 0, total_nblocks, free_bytes > 0, free_chunks
|
||||
from pg_backend_memory_contexts where name = 'Caller tuples';
|
||||
rollback;
|
||||
|
||||
-- At introduction, pg_config had 23 entries; it may grow
|
||||
select count(*) > 20 as ok from pg_config;
|
||||
|
||||
|
|
|
@ -146,6 +146,15 @@ FROM abbrev_abort_uuids
|
|||
ORDER BY ctid DESC LIMIT 5;
|
||||
ROLLBACK;
|
||||
|
||||
----
|
||||
-- test sorting of large datums VALUES
|
||||
----
|
||||
|
||||
-- Ensure the order is correct and values look intact
|
||||
SELECT LEFT(a,10),b FROM
|
||||
(VALUES(REPEAT('a', 512 * 1024),1),(REPEAT('b', 512 * 1024),2)) v(a,b)
|
||||
ORDER BY v.a DESC;
|
||||
|
||||
----
|
||||
-- test forward and backward scans for in-memory and disk based tuplesort
|
||||
----
|
||||
|
|
Loading…
Reference in New Issue