Re: Adding REPACK [concurrently]

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-05-05 15:02:39
Message-ID: afoF8ypBbknkp8_b@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-May-05, Antonin Houska wrote:

> However, I failed to notice that COMMIT record of
> a transaction listed in the xl_running_xacts WAL record is not guaranteed to
> follow the xl_running_xacts record in WAL. In other words, even if
> xl_running_xacts is created before a COMMIT record of the contained
> transaction, it may end up at higher LSN in WAL. So the cleanup I relied on
> might not take place.

That's pretty bad news.

> I've got no good idea how to fix that. Not sure I'm able to pursue the
> "database-specific snapshots" feature now.

It appears that the only reasonable course of action at this point is to
revert 0d3dba38c777.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2026-05-05 15:04:42 Re: Adding REPACK [concurrently]
Previous Message Álvaro Herrera 2026-05-05 14:32:31 Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables