on 19beta3: repack (concurrently) affects sessions with transaction isolation level repeatable read
Hello,
while using repack (concurrently) I found a behavior that I didn't
expect. When running a "repack (concurrently) t;" in one session,
another session with "transaction isolation level repeatable read"
reports sometimes 0 for "select count(*) from t;".
PostgreSQL Version: PostgreSQL 19beta3 on x86_64-pc-linux-gnu, compiled
by gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit
configure command: ./configure --prefix=/home/postgres/pginstall
OS: Red Hat Enterprise Linux 10.2 (Coughlan)
uname -a: Linux lin8.fritz.box 6.12.0-211.44.1.el10_2.x86_64 #1 SMP
PREEMPT_DYNAMIC Tue Aug 4 03:10:19 EDT 2026 x86_64 GNU/Linux
Test Case:
-- create table
drop table if exists t;
create table t (
col1 bigint primary key,
col2 text default 'default text'
);
insert into t (col1) select g from generate_series(1, 10000) as g;
Session 1 runs from time to time: repack (concurrently) t;
Session 2 runs the following script with: while true; do psql mydb -f
./s2.sql; sleep 0.1; done| grep -v "^$"
Script s2.sql:
\pset tuples_only on
\o /dev/null
begin;
set transaction isolation level repeatable read;
select 1;
select pg_sleep(1);
\o
select count(*) from t;
\o /dev/null
end;
Output Session 2:
10000
10000
0
10000
10000
0
10000
10000
10000
0
10000
10000
0
10000
0 always when Session 1 runs: repack (concurrently) t;
Expected Output: Always 10000
Only the (concurrently) option shows this behavior. Wehen using "repack
t;" or "repack t using index t_pkey;" the output is always 10000.
Thanks
Jochen
--
Mit freundlichen Grüßen
Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de
Attachments:
jb.vcftext/vcard; charset=UTF-8; name=jb.vcfDownload
On Sat, Aug 22, 2026 at 3:29 AM Jochen Bandhauer <jb@jbitc.de> wrote:
while using repack (concurrently) I found a behavior that I didn't
expect. When running a "repack (concurrently) t;" in one session,
another session with "transaction isolation level repeatable read"
reports sometimes 0 for "select count(*) from t;".
This is a documented behavior; "repack concurrently" is allowed to
violate MVCC. There's a warning box about this in the docs for the
repack command [1]https://www.postgresql.org/docs/devel/sql-repack.html -- Peter Geoghegan, which notes "REPACK with the CONCURRENTLY option
is not MVCC-safe, see Section 13.6 for details".
[1]: https://www.postgresql.org/docs/devel/sql-repack.html -- Peter Geoghegan
--
Peter Geoghegan
On 22.08.2026 21:45, Peter Geoghegan wrote:
On Sat, Aug 22, 2026 at 3:29 AM Jochen Bandhauer <jb@jbitc.de> wrote:
while using repack (concurrently) I found a behavior that I didn't
expect. When running a "repack (concurrently) t;" in one session,
another session with "transaction isolation level repeatable read"
reports sometimes 0 for "select count(*) from t;".This is a documented behavior; "repack concurrently" is allowed to
violate MVCC. There's a warning box about this in the docs for the
repack command [1], which notes "REPACK with the CONCURRENTLY option
is not MVCC-safe, see Section 13.6 for details".
Hello,
thanks, I haven't seen that. I also read that this might change in the
future [1]/messages/by-id/202504040733.ysuy5gad55md@alvherre.pgsql. After some further reading I applied patch [2]https://commitfest.postgresql.org/patch/6957/ that worked
for the test case (The second session always showed the correct number
of rows).
Jochen
[1]: /messages/by-id/202504040733.ysuy5gad55md@alvherre.pgsql
/messages/by-id/202504040733.ysuy5gad55md@alvherre.pgsql
[2]: https://commitfest.postgresql.org/patch/6957/
--
Mit freundlichen Grüßen
Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de