From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | merryok <merryok(at)163(dot)com> |
Cc: | adrian(dot)klaver(at)aklaver(dot)com, hjp-pgsql(at)hjp(dot)at, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: equivalent thing of mtr in mysql |
Date: | 2022-07-19 03:24:00 |
Message-ID: | F33AF7D9-AC7E-4E5F-8A68-F5ED95CD52A2@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Jul 18, 2022, at 20:03, merryok <merryok(at)163(dot)com> wrote:
>
> I've read the doc, and it doesn't help too much.
> Finally I've found START_CRIT_SECTION and END_CRIT_SECTION. It's like mtr.start(), mtr.commit() in mysql. May I ask why many places are wrapped into START_CRIT_SECTION/END_CRIT_SECTION during a single dml operation ?
A PostgreSQL critical section is not the equivalent of MySQL InnoDB mini-transaction.
A critical section in PostgreSQL is a section of code that needs to run without interruption to avoid corruption of internal in-memory data structures.
PostgreSQL doesn't have a direct equivalent of a MySQL mini-transaction. When WAL information is created by a statement, it's stored in the WAL buffers, and then flushed to disk by the WAL writer (to a first approximation). There's no special operation that groups pages together for atomic writes; that's done by the underlying file system flush operation.
> And if Assert(CritSectionCount > 0) isn't satisfied (CritSectionCount need't be protected ?), PG server will panic and exit ? If so, what's the probability of that ?
If it occurs, it indicates a bug in PostgreSQL. It is *extremely* infrequent (as in, you can go years without seeing one; I can't remember the last time I did).
From | Date | Subject | |
---|---|---|---|
Next Message | Meera Nair | 2022-07-19 04:37:09 | pg_dump is filling C: drive up to 100 percent |
Previous Message | David G. Johnston | 2022-07-19 03:21:13 | Re: Getting the table ID |