From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Fujii Masao <masao.fujii@gmail.com>, Robert Treat <rob@xzilla.net>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: 
 <CADzfLwV+80MfPM=MC5y3nA34djUWuYU6YKcZUO8JjD7_8p7nkg@mail.gmail.com>
References: 
 <CADzfLwXx46j8KwQjjM1ZcqNBsx-k6GxHOzDJkm4SHjh+cv31Rw@mail.gmail.com>
 <202508091333.qvgvo7ikuezm@alvherre.pgsql>
 <CADzfLwW=b=U3e6aasi=XorN8hZSiCKZErKs9qhyK7m=w=wokAg@mail.gmail.com>
 <40729.1755799624@localhost>
 <CADzfLwXpyzGGVB+nbSAMBWDBhzTyn6F2hRrAqcyJd3c6gT2EOQ@mail.gmail.com>
 <9536.1756127358@localhost>
 <CADzfLwWdw=5KhXE5Fr3khytp4mW2girFVJHHb4jSgEncc6237Q@mail.gmail.com>
 <21931.1756136535@localhost>
 <CADzfLwWPihwPM=e=EJ_U5niqDdVyq9pS30ZNxwZ8f_yXyikooQ@mail.gmail.com>
 <24483.1756142534@localhost>
 <CADzfLwUqyOmpkLmciecBy4aBN1sohQVZ2Hgc6m-tjSUqDRHwyQ@mail.gmail.com>
 <4790.1756197960@localhost>
 <CADzfLwV+80MfPM=MC5y3nA34djUWuYU6YKcZUO8JjD7_8p7nkg@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Tue, 26 Aug 2025 11:02:01 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29526.1756215093.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Aug 2025 15:31:33 +0200
Message-ID: <29527.1756215093@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/29527.1756215093%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> Antonin Houska <ah@cybertec.at>:
> =

> > Although it could work, I think it'd be confusing to consider the tran=
sactions
> > being replayed as "current" from the point of view of the backend that
> > executes REPACK CONCURRENTLY.
> =

> Just realized SnapshotDirty is the thing that fits into the role - it
> respects not-yet committed transactions, giving enough information to
> wait for them.
> It is already used in a similar pattern in
> check_exclusion_or_unique_constraint and RelationFindReplTupleByIndex.
> =

> So, it is easy to detect the case of the race you described previously
> and retry + there is no sense to hack around
> TransactionIdIsCurrentTransactionId.

Where exactly should HeapTupleSatisfiesDirty() conclude that the tuple is
visible? TransactionIdIsCurrentTransactionId() will not do w/o the
modifications that you proposed earlier [1] and TransactionIdIsInProgress(=
) is
not suitable as I explained in [2].

I understand your idea that there are no transaction aborts in the new tab=
le,
which makes things simpler. I cannot judge if it's worth inventing a new k=
ind
of snapshot. Anyway, I think you'd then also need to hack
HeapTupleSatisfiesUpdate(). Isn't that too invasive?

[1] https://www.postgresql.org/message-id/CADzfLwUqyOmpkLmciecBy4aBN1sohQV=
Z2Hgc6m-tjSUqDRHwyQ%40mail.gmail.com
[2] https://www.postgresql.org/message-id/24483.1756142534%40localhost

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com