| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2025-08-26 09:02:01 |
| Message-ID: | CADzfLwV+80MfPM=MC5y3nA34djUWuYU6YKcZUO8JjD7_8p7nkg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Antonin Houska <ah(at)cybertec(dot)at>:
> Although it could work, I think it'd be confusing to consider the transactions
> 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.
BWT, btree + SnapshotDirty has issue [0], but it is a different story
and happens only with concurrent updates which are not present in the
current scope.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2025-08-26 09:02:10 | Re: Conflict detection for update_deleted in logical replication |
| Previous Message | Andrei Lepikhov | 2025-08-26 08:58:17 | Re: RFC: extensible planner state |