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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: suppressing useless wakeups in logical/worker.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Something is wrong with wal_compression