Re: Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
Date
Msg-id CAH2-Wz=C_Vj_M8AHZLLb1bajc6bGiehX0goJLWKGwU=D8VGBNw@mail.gmail.com
Whole thread Raw
In response to Re:Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST  (yuansong <yyuansong@126.com>)
List pgsql-hackers
On Sat, Jan 11, 2025 at 4:40 AM yuansong <yyuansong@126.com> wrote:
> If such index anomalies need to be checked, it would be better to do so using external tools rather than checking
duringthe core search process. 

Why? Did you use an external tool?

> If you agree with this proposal, I can try to implement the related fix later.

I strongly disagree.

If the hardening in this function (and similar hardening elsewhere)
had been in place on the production server that you were using (if
you'd kept up with point releases, rather than staying on 13.2) then
you almost certainly wouldn't have had the problem of
btree_xlog_insert crashing in the first place. The problem would have
been contained, and you'd probably only have needed to REINDEX to fix
everything. But you now propose to *remove* that hardening, because it
is "confusing and inefficient". This seems illogical.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Include patch id in commitfest page