Re: Adding REPACK [concurrently]

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>

To: Amit Kapila <amit.kapila16@gmail.com>

Cc: Antonin Houska <ah@cybertec.at>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>

Date: 2026-05-08T23:22:04Z

Lists: pgsql-hackers

On Tue, Apr 7, 2026 at 8:49 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Apr 7, 2026 at 7:49 PM Antonin Houska <ah@cybertec.at> wrote:
> >
> > Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote:
> >
> > > 02. SnapBuildProcessRunningXacts
> > >
> > > Per my understanding, the db_specic snapshot can be also serialized. Is it
> > > possibility tha normal logical decoding system restores the snapshot and obtain
> > > the wrong result?
> >
> > I don't think that the database-specific xl_running_xacts WAL record affects
> > what SnapBuildSerialize() writes to disk: the contents of builder->committed,
> > etc. is updated by decoding COMMIT and ABORT records.
> >
>
> I think the point is that the other process say a walsender could
> restore such a snapshot making it take the wrong decision.
>

Right. I think it affects even concurrent REPACK (CONCURRENTLY)
running on other databases. They could end up restoring the snapshot
serialized by another REPACK command running on another database and
becoming the consistent state without waiting for transactions
concurrently running on the same database, which is clearly wrong.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com