| From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Subject: | Re: Fix bug in multixact Oldest*MXactId initialization and access |
| Date: | 2026-02-26 17:02:38 |
| Message-ID: | ebeb0db1-0eb2-4439-a6c8-1d96b60b25ad@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
26.02.2026 19:34, Sami Imseih пишет:
>> But I still use inline procs for access to the arrays. Asserts cost nothing
>> in release build. And new version of functions doesn't branch.
>
> Asserts may have minimal impact for most builds, but my concern is
> this is all unnecessary complexity. I mean if we guarantee that the
> arrays are initialized correctly, maybe we can have an assert at
> init time, why would we need asserts at run time?
They are future proof.
If there had been assertions from the beginning, there would not have been
a breaking change. The tests would have failed.
(Sorry, I've used Google Translate to write this sentence).
When you write assert, you protect yourself from shooting your leg far in
the future. Believe me.
--
regards
Yura Sokolov aka funny-falcon
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2026-02-26 17:03:01 | Re: MERGE behavior with REPEATABLE READ isolation level |
| Previous Message | Andres Freund | 2026-02-26 16:39:20 | Re: More speedups for tuple deformation |