Thread: installcheck failure in indirect_toast with default_toast_compression = lz4

Hi all,

As said in $subject, installcheck fails once I set up a server with
default_toast_compression = lz4 in the test indirect_toast.  Please
see the attached for the diffs.

The issue is that the ordering of the tuples returned by UPDATE
RETURNING is not completely stable.  Perhaps we should just enforce
the order of those tuples by wrapping the DMLs into a CTE and use an
ORDER BY in the outer query.

Other ideas?
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> The issue is that the ordering of the tuples returned by UPDATE
> RETURNING is not completely stable.  Perhaps we should just enforce
> the order of those tuples by wrapping the DMLs into a CTE and use an
> ORDER BY in the outer query.

Hmm.  I'm not very clear on what that test is intending to test,
but maybe it's dependent on pglz compression, in which case the
right fix would be to force default_toast_compression = pglz
for the duration of the test.

            regards, tom lane

On Fri, Jun 04, 2021 at 08:28:59PM -0400, Tom Lane wrote:
> Hmm.  I'm not very clear on what that test is intending to test,
> but maybe it's dependent on pglz compression, in which case the
> right fix would be to force default_toast_compression = pglz
> for the duration of the test.

Support for external toast datums, as of 36820250, so that should be
independent on the compression method used, no?  I was just sticking
some checks based on pg_column_compression() all over the test, and
all the values are correctly getting compressed and decompressed as
far as I can see.

I got to wonder whether this is not pointing at an actual issue, and
whether it may be better to not make this test rely only on pglz, but
I have not put much thoughts into it TBH.
--
Michael

On Sat, Jun 05, 2021 at 09:20:43AM +0900, Michael Paquier wrote:
> As said in $subject, installcheck fails once I set up a server with
> default_toast_compression = lz4 in the test indirect_toast.  Please
> see the attached for the diffs.
> 
> The issue is that the ordering of the tuples returned by UPDATE
> RETURNING is not completely stable.  Perhaps we should just enforce
> the order of those tuples by wrapping the DMLs into a CTE and use an
> ORDER BY in the outer query.

See also a prior discussion:
https://www.postgresql.org/message-id/CAFiTN-sm8Dpx3q92g5ohTdZu1_wKsw96-KiEMf3SoK8DhRPfWw%40mail.gmail.com

-- 
Justin

On Sun, Jun 06, 2021 at 03:52:57PM -0500, Justin Pryzby wrote:
> See also a prior discussion:
> https://www.postgresql.org/message-id/CAFiTN-sm8Dpx3q92g5ohTdZu1_wKsw96-KiEMf3SoK8DhRPfWw%40mail.gmail.com

Ah, thanks for the reference.  So this was discussed but not actually
fixed.  I can see the data getting stored inline rather than
externalized with lz4.  So, as the goal of the test is to stress the
case of externalized values, we'd better make sure that pglz is used.
I'll push something doing that with more comments added to the test.
--
Michael