Some tests for TOAST, STORAGE MAIN/EXTENDED
Hi all,
While playing with the TOAST code this week, I have managed to break
the handling of inline compressible entries, and noticed that the main
regression test suite did not complain following that.
Breaking that stuff is my issue, but I would like to add some
regression tests to cover all that, giving the attached. This also
includes tests with EXTENDED in the same area, while on it, with
checks for the TOAST table itself.
Thoughts or comments?
--
Michael
Attachments:
0001-More-tests-for-TOAST-and-STORAGE.patchtext/x-diff; charset=us-asciiDownload+74-1
Hi Michael,
On Thu, Jan 22, 2026 at 11:04 PM Michael Paquier <michael@paquier.xyz> wrote:
Thoughts or comments?
Two nits on the new toasttest block:
The `SELECT count(*) FROM :reltoastname` assertion is a bit brittle
for `STORAGE EXTENDED`: depending on the toast compression method /
effectiveness, the value may end up as >1 chunk, which would flip the
expected count(*) = 1. Prefer SELECT count(DISTINCT chunk_id) FROM
:reltoastname (or WHERE chunk_seq = 0) and adjust expected.
pg_column_compression() expects pglz, but default_toast_compression
isn’t pinned here. Suggest SET default_toast_compression = 'pglz';
near this block; otherwise this can fail on builds with a different
default.
--
Nikhil Veldanda
On Fri, Jan 23, 2026 at 12:25:33AM -0800, Nikhil Kumar Veldanda wrote:
The `SELECT count(*) FROM :reltoastname` assertion is a bit brittle
for `STORAGE EXTENDED`: depending on the toast compression method /
effectiveness, the value may end up as >1 chunk, which would flip the
expected count(*) = 1. Prefer SELECT count(DISTINCT chunk_id) FROM
:reltoastname (or WHERE chunk_seq = 0) and adjust expected.
Yeah, this suggestion sounds sensible and that would still notice what
I was able to break.
pg_column_compression() expects pglz, but default_toast_compression
isn’t pinned here. Suggest SET default_toast_compression = 'pglz';
near this block; otherwise this can fail on builds with a different
default.
Agreed, let's do that as well.
--
Michael
On Sun, Jan 25, 2026 at 09:46:51AM +0900, Michael Paquier wrote:
On Fri, Jan 23, 2026 at 12:25:33AM -0800, Nikhil Kumar Veldanda wrote:
The `SELECT count(*) FROM :reltoastname` assertion is a bit brittle
for `STORAGE EXTENDED`: depending on the toast compression method /
effectiveness, the value may end up as >1 chunk, which would flip the
expected count(*) = 1. Prefer SELECT count(DISTINCT chunk_id) FROM
:reltoastname (or WHERE chunk_seq = 0) and adjust expected.Yeah, this suggestion sounds sensible and that would still notice what
I was able to break.
I have settled down to the addition of a qual based on chunk_seq,
being consistent with the other test, at the end, then applied the
result as 168765e5d42b. Thanks for the suggestions, Nikhil.
--
Michael