Re: [PATCH] Full support for index LP_DEAD hint bits on standby - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [PATCH] Full support for index LP_DEAD hint bits on standby
Date
Msg-id CAH2-Wz=O3-kyBZw5dTZkgVMkvF5MiMUpNPTQ0k8WLf-tkhMjBg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Full support for index LP_DEAD hint bits on standby  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Responses Re: [PATCH] Full support for index LP_DEAD hint bits on standby  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [PATCH] Full support for index LP_DEAD hint bits on standby  (Michail Nikolaev <michail.nikolaev@gmail.com>)
List pgsql-hackers
On Tue, Mar 29, 2022 at 4:55 AM Michail Nikolaev
<michail.nikolaev@gmail.com> wrote:
> > Overall, I think that this patch has serious design flaws, and that
> > this issue is really just a symptom of a bigger problem.
>
> Could you please advise me on something? The ways I see:
> * give up :)

I would never tell anybody to give up on something like this, because
I don't really have the right to do so. And because it really isn't my
style.

> * try to fix this concept
> * go back to concept with LP_DEAD horizon WAL and optional cancellation
> * try to limit scope on “allow standby to use LP_DEAD set on primary

The simple answer is: I don't know. I could probably come up with a
better answer than that, but it would take real effort, and time.

> in some cases” (by marking something in btree page probably)
> * look for some new way

You seem like a smart guy, and I respect the effort that you have put
in already -- I really do. But I think that you have unrealistic ideas
about how to be successful with a project like this.

The reality is that the Postgres development process gives authority
to a relatively small number of committers. This is not a perfect
system, at all, but it's the best system that we have. Only a minority
of the committers are truly experienced with the areas of the code
that your patch touches -- so the number of people that are ever
likely to commit a patch like that is very small (even if the patch
was perfect). You need to convince at least one of them to do so, or
else your patch doesn't get into PostgreSQL, no matter what else may
be true. I hope that my remarks don't seem disdainful or belittling --
that is not my intention. These are just facts.

I think that you could do a better job of explaining and promoting the
problem that you're trying to solve here. Emphasis on the problem, not
so much the solution. Only a very small number of patches don't need
to be promoted. Of course I can see that the general idea has merit,
but that isn't enough. Why do *you* care about this problem so much?
The answer isn't self-evident. You have to tell us why it matters so
much.

You must understand that this whole area is *scary*. The potential for
serious data corruption bugs is very real. And because the whole area
is so complicated (it is at the intersection of 2-3 complicated
areas), we can expect those bugs to be hidden for a long time. We
might never be 100% sure that we've fixed all of them if the initial
design is not generally robust. Most patches are not like that.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Next
From: Andres Freund
Date:
Subject: Re: Add parameter jit_warn_above_fraction