| 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-25 18:18:17 |
| Message-ID: | CADzfLwUqyOmpkLmciecBy4aBN1sohQVZ2Hgc6m-tjSUqDRHwyQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Antonin Houska <ah(at)cybertec(dot)at>:
> I think the problem is that HeapTupleSatisfiesSelf() uses
> TransactionIdIsInProgress() instead of checking the snapshot:
Yes, some issues might be possible for SnapshotSelf.
Possible solution is to override TransactionIdIsCurrentTransactionId
to true (like you did with nParallelCurrentXids but just return true).
IIUC, in that case all checks are going to behave the same way as in v5 version.
> I'd prefer optimization of the logical decoding for REPACK CONCURRENTLY, and
> using the MVCC snapshots.
It is also possible, but it is much more complex and feels like overkill to me.
We need just a way to find the latest version of row in the world of
all-committed transactions without any concurrent writers - I am
pretty sure it is possible to achieve in a more simple and effective
way.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-08-25 18:29:31 | Re: Support getrandom() for pg_strong_random() source |
| Previous Message | Sami Imseih | 2025-08-25 17:58:08 | Re: GetNamedLWLockTranche crashes on Windows in normal backend |