Re: Something is wrong with wal_compression
От | Thomas Munro |
---|---|
Тема | Re: Something is wrong with wal_compression |
Дата | |
Msg-id | CA+hUKGLO25PfF0Mnbec=M6pVbcg6_Jib_UXt5DEcfvVc-N7cOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Something is wrong with wal_compression (Andrey Borodin <amborodin86@gmail.com>) |
Ответы |
Re: Something is wrong with wal_compression
|
Список | pgsql-hackers |
On Sat, Jan 28, 2023 at 4:57 PM Andrey Borodin <amborodin86@gmail.com> wrote: > It's not trustworthy anyway. Xid wraparound might happen during > reconnect. I suspect we can design a test that will show that it does > not always show correct results during xid->2pc conversion (there is a > point in time when xid is not in regular and not in 2pc, and I'm not > sure ProcArrayLock is held). Maybe there are other edge cases. I'm not sure I understand the edge cases, but it is true that this can only give you the answer until the CLOG is truncated, which is pretty arbitrary and you could be unlucky. I guess a reliable version of this would have new policies about CLOG retention, and CLOG segment filenames derived from 64 bit xids so they don't wrap around. > Anyway, if a user wants to know the status of xid in case of > disconnection they have prepared xacts. Yeah. The original proposal mentioned that, but that this was a "lighter" alternative. Reading Andres's comments and realising how relatively young txid_status() is compared to txid_current(), I'm now wondering if we shouldn't just disclaim the whole thing in back branches. Maybe if we want to rescue it in master, there could be a "reliable" argument, defaulting to false, or whatever, and we could eventually make the amortisation improvement.
В списке pgsql-hackers по дате отправления: