| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, reid(dot)thompson(at)crunchydata(dot)com, Tristan Partin <tristan(at)neon(dot)tech>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Refactoring backend fork+exec code |
| Date: | 2024-02-15 05:09:44 |
| Message-ID: | CA+Tgmoa=m3qogg1QH8kbicTgCtipgK1hTUDWpHd5SBra7kV6Ew@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 15, 2024 at 3:07 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think the last remaining question here is about the 0- vs 1-based indexing
> > of BackendIds. Is it a good idea to switch to 0-based indexing? And if we do
> > it, should we reserve PGPROC 0. I'm on the fence on this one.
>
> I lean towards it being a good idea. Having two internal indexing schemes was
> bad enough so far, but at least one would fairly quickly notice if one used
> the wrong one. If they're just offset by 1, it might end up taking longer,
> because that'll often also be a valid id.
Yeah, I think making everything 0-based is probably the best way
forward long term. It might require more cleanup work to get there,
but it's just a lot simpler in the end, IMHO.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-02-15 05:09:45 | Re: Fix race condition in InvalidatePossiblyObsoleteSlot() |
| Previous Message | Robert Haas | 2024-02-15 05:05:13 | Re: index prefetching |