Re: POC: make mxidoff 64 bits
| От | Maxim Orlov |
|---|---|
| Тема | Re: POC: make mxidoff 64 bits |
| Дата | |
| Msg-id | CACG=ezY0=ri8A0duXbpd1XNUc1jnngaPnmB0-+UZpxAv7-fNtw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: POC: make mxidoff 64 bits (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: POC: make mxidoff 64 bits
|
| Список | pgsql-hackers |
On Tue, 25 Nov 2025 at 13:07, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
GetOldMultiXactIdSingleMember() currently asserts that the offset is
never zero, but it should try to do something sensible in that case
instead of just failing.
Correct me if I'm wrong, but we added the assertion that offsets are
never 0, based on the idea that case #2 will never take place during an
update. If this isn't the case, this assertion could be removed.
The rest of the function appears to work correctly.
I even think that, as an experiment, we could randomly reset some of the
offsets to zero and nothing would happen, except that some data would
never 0, based on the idea that case #2 will never take place during an
update. If this isn't the case, this assertion could be removed.
The rest of the function appears to work correctly.
I even think that, as an experiment, we could randomly reset some of the
offsets to zero and nothing would happen, except that some data would
be lost.
The most sensible thing we can do is give the user a warning, right?
Something like, "During the update, we encountered some weird offset
that shouldn't have been there, but there's nothing we can do about it,
just take note."
The most sensible thing we can do is give the user a warning, right?
Something like, "During the update, we encountered some weird offset
that shouldn't have been there, but there's nothing we can do about it,
just take note."
--
Best regards,
Maxim Orlov.
В списке pgsql-hackers по дате отправления: