Re: Adding REPACK [concurrently]
От | Robert Treat |
---|---|
Тема | Re: Adding REPACK [concurrently] |
Дата | |
Msg-id | CAJSLCQ36BynNAC2vYuWkJ-Y-rECRFoE4rB7NV-O+ENE3bKdp4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Adding REPACK [concurrently] (Mihail Nikalayeu <mihailnikalayeu@gmail.com>) |
Ответы |
Re: Adding REPACK [concurrently]
|
Список | pgsql-hackers |
On Mon, Aug 25, 2025 at 10:15 AM Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote: > 1) we have a whole initial table snapshot with all xmin copied from > the original table. All such xmin are committed. > 2) appling transaction sees ALL the self-alive (no xmax) tuple in it > because its xmin\xmax is committed and SnapshotSelf is happy with it > 3) each update/delete during the replay selects the last existing > tuple version, updates it xmax=original xid and inserts a new one > keeping with xmin=orignal xid > 4) --//-- > 5) --//-- > Advancing the tables min xid to at least repack XID is a pretty big feature, but the above scenario sounds like it would result in any non-modified pre-existing tuples ending up with their original xmin rather than repack XID, which seems like it could lead to weird side-effects. Maybe I am mis-thinking it though? Robert Treat https://xzilla.net
В списке pgsql-hackers по дате отправления: