| From: | Stan Hu <stanhu(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: lastOverflowedXid does not handle transaction ID wraparound |
| Date: | 2021-10-21 14:20:57 |
| Message-ID: | CAMBWrQkjs63=en7swzSodGhuuukq+nYfZEMtv1UtpYPfH3u2=w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 20, 2021 at 9:01 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> lastOverflowedXid is the smallest subxid that possibly exists but
> possiblly not known to the standby. So if all top-level transactions
> older than lastOverflowedXid end, that means that all the
> subtransactions in doubt are known to have been ended.
Thanks for the patch! I verified that it appears to reset
lastOverflowedXid properly.
I may not be understanding
https://github.com/postgres/postgres/blob/dc899146dbf0e1d23fb24155a5155826ddce34c9/src/backend/storage/ipc/procarray.c#L1326-L1327
correctly, but isn't lastOverflowedXid the last subxid for a given
top-level XID, so isn't it actually the largest subxid that possibly
exists?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-10-21 14:28:52 | Re: Assorted improvements in pg_dump |
| Previous Message | Japin Li | 2021-10-21 14:17:55 | Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber |