Horton

Thread

Commits

  1. Back-patch b1ffe3ff into REL_13_STABLE.

  1. Bug in v13 due to "Fix corruption when relation truncation fails."

    Yura Sokolov <y.sokolov@postgrespro.ru> — 2024-12-26T10:10:59Z

    Good day.

Commit "Fix corruption when relation truncation fails." [0] makes 
smgrtruncate be called in a critical section. Unfortunately in version 
13 it leads to occasional call to palloc0 inside of critical section, 
which triggers Assert in debug builds:

- smgrtruncate calls mdtruncate
- mdtruncate may call register_dirty_segment
- register_dirty_segment calls RegisterSyncRequest
- RegisterSyncRequest calls ForwardSyncRequest
- ForwardSyncRequest may call CompactCheckpointerRequestQueue
- CompactCheckpointerRequestQueue may call palloc0 ...

In versions 14 and above CompactCheckpointerRequestQueue does check for 
critical section due to commit "Fix bugs in MultiXact truncation" [1],
which were backported down to 14 version, but not 13.

We caught it in our private tests, so it is real.
Cherry-pick of [1] from 14 version to 13 solves the issue.

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;h=2280912165d
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c8e00ae9ae

------

regards,
Yura Sokolov aka funny-falcon

  2. Re: Bug in v13 due to "Fix corruption when relation truncation fails."

    Michael Paquier <michael@paquier.xyz> — 2025-01-08T03:30:51Z

    On Thu, Dec 26, 2024 at 01:10:59PM +0300, Yura Sokolov wrote:
> Commit "Fix corruption when relation truncation fails." [0] makes
> smgrtruncate be called in a critical section. Unfortunately in version 13 it
> leads to occasional call to palloc0 inside of critical section, which
> triggers Assert in debug builds:
> 
> - smgrtruncate calls mdtruncate
> - mdtruncate may call register_dirty_segment
> - register_dirty_segment calls RegisterSyncRequest
> - RegisterSyncRequest calls ForwardSyncRequest
> - ForwardSyncRequest may call CompactCheckpointerRequestQueue
> - CompactCheckpointerRequestQueue may call palloc0 ...
> 
> In versions 14 and above CompactCheckpointerRequestQueue does check for
> critical section due to commit "Fix bugs in MultiXact truncation" [1],
> which were backported down to 14 version, but not 13.
> 
> We caught it in our private tests, so it is real.
> Cherry-pick of [1] from 14 version to 13 solves the issue.
> 
> [0] https://git.postgresql.org/gitweb/?p=postgresql.git;h=2280912165d
> [1] https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c8e00ae9ae

Ah, you're right.  This chain of events is possible in REL_13_STABLE,
and only there.  Thomas?
--
Michael

  3. Re: Bug in v13 due to "Fix corruption when relation truncation fails."

    Thomas Munro <thomas.munro@gmail.com> — 2025-01-08T04:59:48Z

    On Wed, Jan 8, 2025 at 4:31 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Dec 26, 2024 at 01:10:59PM +0300, Yura Sokolov wrote:
> > Commit "Fix corruption when relation truncation fails." [0] makes
> > smgrtruncate be called in a critical section. Unfortunately in version 13 it
> > leads to occasional call to palloc0 inside of critical section, which
> > triggers Assert in debug builds:
> >
> > - smgrtruncate calls mdtruncate
> > - mdtruncate may call register_dirty_segment
> > - register_dirty_segment calls RegisterSyncRequest
> > - RegisterSyncRequest calls ForwardSyncRequest
> > - ForwardSyncRequest may call CompactCheckpointerRequestQueue
> > - CompactCheckpointerRequestQueue may call palloc0 ...
> >
> > In versions 14 and above CompactCheckpointerRequestQueue does check for
> > critical section due to commit "Fix bugs in MultiXact truncation" [1],
> > which were backported down to 14 version, but not 13.
> >
> > We caught it in our private tests, so it is real.
> > Cherry-pick of [1] from 14 version to 13 solves the issue.
> >
> > [0] https://git.postgresql.org/gitweb/?p=postgresql.git;h=2280912165d
> > [1] https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c8e00ae9ae
>
> Ah, you're right.  This chain of events is possible in REL_13_STABLE,
> and only there.  Thomas?

Yeah.  4c8e00ae9ae addressed two separate issues: (1) another critical
section thing just like this one, and this one in passing, and (2) a
deadlock risk involving checkpoint delays.  I had actually worried
about that exact deadlock scenario a bit earlier[1] and figured out
that it couldn't happen in this code path, so I guess we technically
only need to back-patch the couple of lines with the fast return, but
it seems harmless, simple and good to back-patch Heikki's whole patch
from 14->13.  I will study this a bit more and then go ahead and do
that.  Thanks for the report, Yura, and the reminder, Michael.

[1] https://www.postgresql.org/message-id/CA%2BhUKGJC%2BEDcjXFoeOopcE7zxDwASUyWXh8RkRkgbq%3DvYTQ-qg%40mail.gmail.com