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

From Bruce Momjian
Subject Re: Let's make PostgreSQL multi-threaded
Date
Msg-id ZH56vC2CSXUvTsqU@momjian.us
Whole thread Raw
In response to Re: Let's make PostgreSQL multi-threaded  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Let's make PostgreSQL multi-threaded
Re: Let's make PostgreSQL multi-threaded
List pgsql-hackers
On Mon, Jun  5, 2023 at 04:50:11PM -0700, Peter Geoghegan wrote:
> On Mon, Jun 5, 2023 at 4:26 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I remember we used to have macros we called before we modified critical
> > parts of shared memory, and if a process exited while in those blocks,
> > the server would restart.  Unfortunately, I can't find that in the code
> > now.
> 
> Isn't that what we call a critical section? They effectively "promote"
> any ERROR (e.g., from an OOM) into a PANIC.
> 
> I thought that we only used critical sections for things that are
> WAL-logged, but I double checked just now. Turns out that I was wrong:
> PGSTAT_BEGIN_WRITE_ACTIVITY() contains its own START_CRIT_SECTION(),
> despite not being involved in WAL logging. And so critical sections
> could indeed be described as something that we use whenever shared
> memory cannot be left in an inconsistent state (which often coincides
> with WAL logging, but need not).

Yes, sorry, critical sections is what I was remembering.  My question is
whether all unexpected backend exits should be treated as critical
sections?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Partial aggregates pushdown
Next
From: Jeremy Schneider
Date:
Subject: Re: Let's make PostgreSQL multi-threaded