Re: Let's make PostgreSQL multi-threaded - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Let's make PostgreSQL multi-threaded
Date
Msg-id CAFiTN-tF+K0QwOS84Dbz4K2sr1bBo=-pAeTta9wg0sVBwDRawQ@mail.gmail.com
Whole thread Raw
In response to Re: Let's make PostgreSQL multi-threaded  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 6, 2023 at 11:30 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jun 6, 2023 at 11:46 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Bruce was worried about the loss of isolation that the separate address
> > spaces gives, and Jeremy shared an anecdote on that. That is an
> > objection to the idea itself, i.e. even if transition was smooth,
> > bug-free and effortless, that point remains. I personally think the
> > isolation we get from separate address spaces is overrated. Yes, it
> > gives you some protection, but given how much shared memory there is,
> > the blast radius is large even with separate backend processes.
>
> An interesting idea might be to look at the places where we ereport or
> elog FATAL due to some kind of backend data structure corruption and
> ask whether there would be an argument for elevating the level to
> PANIC if we changed this. There are definitely some places where we
> argue that the only corrupted state is backend-local and thus we don't
> need to PANIC if it's corrupted. I wonder to what extent this change
> would undermine that argument.

With the threaded model, that shouldn't change, right? Even though all
memory space is now shared across threads, we can maintain the same
rules for modifying critical shared data structures, i.e. modifying
such memory should still fall under the CRITICAL SECTION, so I guess
the rules for promoting error level to PANIC will remain the same.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: 謝東霖
Date:
Subject: Re: Improve join_search_one_level readibilty (one line change)
Next
From: Dilip Kumar
Date:
Subject: Re: Let's make PostgreSQL multi-threaded