Re: Online checksums patch - once again

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Online checksums patch - once again
Date: 2021-02-11 13:10:10
Message-ID: 20210211131010.GA14327@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 10, 2021 at 01:26:18PM -0500, Bruce Momjian wrote:
> On Wed, Feb 10, 2021 at 03:25:58PM +0100, Magnus Hagander wrote:
> > A fairly large amount of this complexity comes out of the fact that it
> > now supports restarting and tracks checksums on a per-table basis. We
> > skipped this in the original patch for exactly this reason (that's not
> > to say there isn't a fair amount of complexity even without it, but it
> > did substantially i increase both the size and the complexity of the
> > patch), but in the review of that i was specifically asked for having
> > that added. I personally don't think it's worth that complexity but at
> > the time that seemed to be a pretty strong argument. So I'm not
> > entirely sure how to move forward with that...
> >
> > is your impression that it would still be too complicated, even without that?
>
> I was wondering why this feature has stalled for so long --- now I know.
> This does highlight the risk of implementing too many additions to a
> feature. I am working against this dynamic in the cluster file
> encryption feature I am working on.

Oh, I think another reason this patchset has had problems is related to
something I mentioned in 2018:

https://www.postgresql.org/message-id/20180801163613.GA2267@momjian.us

This patchset is weird because it is perhaps our first case of trying to
change the state of the server while it is running. We just don't have
an established protocol for how to orchestrate that, so we are limping
along toward a solution. Forcing a restart is probably part of that
primitive orchestration. We will probably have similar challenges if we
ever allowed Postgres to change its data format on the fly. These
challenges are one reason pg_upgrade only modifies the new cluster,
never the old one.

I don't think anyone has done anything wrong --- rather, it is what we
are _trying_ to do that is complex. Adding restartability to this just
added to the challenge.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2021-02-11 13:20:38 Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
Previous Message Ashutosh Bapat 2021-02-11 13:09:45 Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)