Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfdrk-003gff-2g for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 12:51:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfdrj-004n3G-2w for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 12:51:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfdrj-004n36-1U for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 12:51:19 +0000 Received: from mail-dy1-x1342.google.com ([2607:f8b0:4864:20::1342]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfdrg-000Cdh-29 for pgsql-hackers@postgresql.org; Tue, 13 Jan 2026 12:51:18 +0000 Received: by mail-dy1-x1342.google.com with SMTP id 5a478bee46e88-2b4520f6b32so1169397eec.0 for ; Tue, 13 Jan 2026 04:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768308676; x=1768913476; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7958sPlZrc40qEhuM/+Gp92kkwjxJhxeUSmk0dBoh24=; b=TIPxgy94ZuTLRtl9OJDiY5EvYoNrdwoYPuh1LXZCdwLFtp6Um/rje8OgI4u1+sGLDz bcXBCFSGEkaqTANeSx+uch6dh4bSK8OVlILXVN5LtXhxe4AhC2k5ZMOl4FcLstcHkIiX 0q8bFRwmkbjtY8/Q0bParYo6189JUwsFLtk2EExmMUgGHC5EOdWmjWzCTe3PEPyhkv4N vJOPmOA/UYrphPej9Dd35Mz4ZiQYVR9+vIlLlEcpiDhchwx/QZQ0lu+hxtYJSbBrb8Hu 6l29TjbA6QVMGo3TfI95XqtmUNrwbDrhJ+mpcvpd6wryIAlWu5cXSWkREdJWvobnVeyC vZ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768308676; x=1768913476; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7958sPlZrc40qEhuM/+Gp92kkwjxJhxeUSmk0dBoh24=; b=lj2+3luPfq8lyhJMIALUAF7SR5ik+NrYuQVRwxkHbkTCL+74VWUjahnkpKc2r4bDLe zXlBQ+Or1kdZl3zvH+FiLEC9Hti0IZfZK+z5Spa1Dk8wQvLcrQV49CME0T4S+ZZpN/WM zGfMg5aojzX31MMHk4NcLn6R0aB4c8FHW4yilyCQvzbMhF8ZKWOIUanUP+Xl9MLV/6Ih VqgLs9KxgDOGHk3HMvxkccJ4Ontnk4ec0/Z7619T4ki10eMTI5t5FspG3FSqYnDgC3SO sJP57JsCV9IdeNZbi8S9NzCPa3lHkWPCSMUQgYdPSAtei+XXz8xMfOa34TnJBWd9vB7M VDzA== X-Gm-Message-State: AOJu0Yw1YLsqMdf/leeSe08a0q9PaSU5etTZBcfcXcXsjT1HkZ/Pqghg hgv3hqQulWTpFR9iavUaTZw5A4B7eH67IjOG7onf69TOSu1PF/svYZ2ROdbYY5Dql6uchd/CvRA vvSINil5Uu2buOY5klXm8aClAdgQMY9k= X-Gm-Gg: AY/fxX63os8XF49g7vZ5CoExKcUM3H6PvQx9ZR1wr5UrYXF1pHVGLdbjmUhXbwZcSex s7/TBh8gC09s22jQ+xWdo9Z8WPhm7lx0A63G8JHefI/SRlXArzphml1tSRjg/gJbezqnfxDjZU4 KlKwt9GNFV9bPUIHrwZbu3kPx1lt0A+YH8WMFTQ7VkczN5j2VHagc2/Ge1OY+HsI96+Sp2pC/F1 dwwrNZRmOhhRmvzEk28M5MsuTHB7IT/PSkda8evN8QdGlTKNCmceIy7nB/6cAC2zt+QneM= X-Google-Smtp-Source: AGHT+IEEAi/WFXbGWtWkFUBcRp1yCbNeFhKTw2jLu3+Y5/UaZa/K9W+v0d2G/c3Nn8utdW2CrGtGXCaOiZX9O9RRPgk= X-Received: by 2002:a05:7300:fb95:b0:2ae:566b:1213 with SMTP id 5a478bee46e88-2b17d2e36c8mr16568862eec.28.1768308676000; Tue, 13 Jan 2026 04:51:16 -0800 (PST) MIME-Version: 1.0 References: <7bcc0420-d457-4af5-a459-a4e5d929a665@vondra.me> <7gbzkoxrpqvj2sgxof4pqirz7pf6wb5vizak3mxrz2zpvrf3pa@lvnwdsy3em56> In-Reply-To: From: lakshmi Date: Tue, 13 Jan 2026 18:23:16 +0530 X-Gm-Features: AZwV_Qj1jrm5skQx7bmj26r9vVddz4kVk84whywkapr00_9VCZ5UoF7o2uK4zVU Message-ID: Subject: Re: Proposal: Adding compression of temporary files To: Filip Janus Cc: pgsql-hackers@postgresql.org Content-Type: multipart/alternative; boundary="0000000000007c80f90648447260" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007c80f90648447260 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I tried to replicate the temporary file compression issue by applying the two patches shared in the thread on current PostgreSQL master. here is what i observed, 1) patch 1:0001-Add-transparent-compression-for-temporary-files.patch when applying the first patch it ultimately fails to apply due to context mismatches. failures i see are in the following files: src/backend/storage/file/buffile.c src/backend/utils/misc/guc_tables.c src/backend/utils/misc/postgresql.conf.sample 2) The second patch 0002-Add-regression-tests-for-temporary-file-compression.patch ,applies successfully without any issues. Does it mean that the implementation patch needs to be rebased or otherwise adjusted for the current codebase, and if so, what would be the recommended way to proceed?could you please suggest how I should apply the implementation patch in this case? regards lakshmi On Tue, Jan 13, 2026 at 5:01=E2=80=AFPM Filip Janus wro= te: > Rebase after changes introduced in guc_tables.c > > -Filip- > > > =C3=BAt 19. 8. 2025 v 17:48 odes=C3=ADlatel Filip Janus napsal: > >> Fix overlooked compiler warnings >> >> -Filip- >> >> >> po 18. 8. 2025 v 18:51 odes=C3=ADlatel Filip Janus n= apsal: >> >>> I rebased the proposal and fixed the problem causing those problems. >>> >>> -Filip- >>> >>> >>> =C3=BAt 17. 6. 2025 v 16:49 odes=C3=ADlatel Andres Freund >>> napsal: >>> >>>> Hi, >>>> >>>> On 2025-04-25 23:54:00 +0200, Filip Janus wrote: >>>> > The latest rebase. >>>> >>>> This often seems to fail during tests: >>>> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5382 >>>> >>>> E.g. >>>> >>>> https://api.cirrus-ci.com/v1/artifact/task/4667337632120832/testrun/bu= ild-32/testrun/recovery/027_stream_regress/log/regress_log_027_stream_regre= ss >>>> >>>> =3D=3D=3D dumping >>>> /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream_regress/data= /regression.diffs >>>> =3D=3D=3D >>>> diff -U3 >>>> /tmp/cirrus-ci-build/src/test/regress/expected/join_hash_pglz.out >>>> /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream_regress/data= /results/join_hash_pglz.out >>>> --- /tmp/cirrus-ci-build/src/test/regress/expected/join_hash_pglz.out >>>> 2025-05-26 05:04:40.686524215 +0000 >>>> +++ >>>> /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream_regress/data= /results/join_hash_pglz.out >>>> 2025-05-26 05:15:00.534907680 +0000 >>>> @@ -594,11 +594,8 @@ >>>> select count(*) from join_foo >>>> left join (select b1.id, b1.t from join_bar b1 join join_bar b2 >>>> using (id)) ss >>>> on join_foo.id < ss.id + 1 and join_foo.id > ss.id - 1; >>>> - count >>>> -------- >>>> - 3 >>>> -(1 row) >>>> - >>>> +ERROR: could not read from temporary file: read only 8180 of 1572860 >>>> bytes >>>> +CONTEXT: parallel worker >>>> select final > 1 as multibatch >>>> from hash_join_batches( >>>> $$ >>>> @@ -606,11 +603,7 @@ >>>> left join (select b1.id, b1.t from join_bar b1 join join_bar b2 >>>> using (id)) ss >>>> on join_foo.id < ss.id + 1 and join_foo.id > ss.id - 1; >>>> $$); >>>> - multibatch >>>> ------------- >>>> - t >>>> -(1 row) >>>> - >>>> +ERROR: current transaction is aborted, commands ignored until end of >>>> transaction block >>>> rollback to settings; >>>> -- single-batch with rescan, parallel-oblivious >>>> savepoint settings; >>>> >>>> >>>> Greetings, >>>> >>>> Andres >>>> >>>> >>>> --0000000000007c80f90648447260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
I tried to replicate the temporary file compres= sion issue by applying the two patches shared in the thread on current Post= greSQL master.
here is what i observed,
1) patch 1:0001-Add-transpare= nt-compression-for-temporary-files.patch
when applying the first patch i= t ultimately fails to apply due to context mismatches.

failures i se= e are in the following files:
src/backend/storage/file/buffile.c
src/backend/utils/misc/guc_tables.c
src/backend/utils/misc/postgresql.conf.sample

2) The second patc= h=C2=A00002-Add-regression-tests-for-temporary-file-compression.patch ,appl= ies successfully without any issues.

Does it mean that the impl= ementation patch needs to be rebased or otherwise adjusted for the current = codebase, and if so, what would be the recommended way to proceed?could you= please suggest how I should apply the implementation patch in this case?

regards
lakshmi

On Tue, Jan 13, 202= 6 at 5:01=E2=80=AFPM Filip Janus <f= janus@redhat.com> wrote:
Rebase after changes=C2=A0introduced = in guc_tables.c

=C2=A0 =C2=A0 -= Filip-


=C3=BAt 19. 8. 2025 v=C2=A017:48 od= es=C3=ADlatel Filip Janus <fjanus@redhat.com> napsal:
Fix overlooked compiler= warnings=C2=A0

=C2=A0 =C2=A0 -= Filip-


po 18. 8. 2025 v=C2=A018:51 odes=C3= =ADlatel Filip Janus <fjanus@redhat.com> napsal:
I rebased the proposal and fix= ed=C2=A0the problem causing those problems.

=C2=A0 =C2=A0 -Filip-

<= br>
=C3=BAt= 17. 6. 2025 v=C2=A016:49 odes=C3=ADlatel Andres Freund <andres@anarazel.de> napsal:=
Hi,

On 2025-04-25 23:54:00 +0200, Filip Janus wrote:
> The latest rebase.

This often seems to fail during tests:
https://cirrus-ci.com/github/postg= resql-cfbot/postgresql/cf%2F5382

E.g.
https://api.cirrus-ci.com/v1= /artifact/task/4667337632120832/testrun/build-32/testrun/recovery/027_strea= m_regress/log/regress_log_027_stream_regress

=3D=3D=3D dumping /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream= _regress/data/regression.diffs =3D=3D=3D
diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/join_hash_pglz.out = /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream_regress/data/resu= lts/join_hash_pglz.out
--- /tmp/cirrus-ci-build/src/test/regress/expected/join_hash_pglz.out=C2=A0= =C2=A02025-05-26 05:04:40.686524215 +0000
+++ /tmp/cirrus-ci-build/build-32/testrun/recovery/027_stream_regress/data/= results/join_hash_pglz.out=C2=A0 =C2=A02025-05-26 05:15:00.534907680 +0000<= br> @@ -594,11 +594,8 @@
=C2=A0select count(*) from join_foo
=C2=A0 =C2=A0left join (select b1.id, b1.t from join_bar b1 join join_bar b2 using (= id)) ss
=C2=A0 =C2=A0on join_foo.id < ss.id + 1 and join_foo.id > ss.id - 1;
- count
--------
-=C2=A0 =C2=A0 =C2=A03
-(1 row)
-
+ERROR:=C2=A0 could not read from temporary file: read only 8180 of 1572860= bytes
+CONTEXT:=C2=A0 parallel worker
=C2=A0select final > 1 as multibatch
=C2=A0 =C2=A0from hash_join_batches(
=C2=A0$$
@@ -606,11 +603,7 @@
=C2=A0 =C2=A0 =C2=A0left join (select b1.id, b1.t from join_bar b1 join join_bar b2 = using (id)) ss
=C2=A0 =C2=A0 =C2=A0on join_foo.id < ss.id + 1 and join_foo.id > ss.id - 1;
=C2=A0$$);
- multibatch
-------------
- t
-(1 row)
-
+ERROR:=C2=A0 current transaction is aborted, commands ignored until end of= transaction block
=C2=A0rollback to settings;
=C2=A0-- single-batch with rescan, parallel-oblivious
=C2=A0savepoint settings;


Greetings,

Andres


--0000000000007c80f90648447260--