Re: [PATCHES] Post-special page storage TDE support

From: David Christensen <david(dot)christensen(at)crunchydata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: [PATCHES] Post-special page storage TDE support
Date: 2024-12-12 15:15:55
Message-ID: CAOxo6XLa_b6HLBmyPVJ77MK3TZABe5qz2BuTB=XWtsqHr9NurQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 10, 2024 at 12:54 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Mar 13, 2024 at 11:26:48AM -0500, David Christensen wrote:
> > Enclosing v4 for this patch series, rebased atop the
> > constant-splitting series[1]. For the purposes of having cfbot happy,
> > I am including the prerequisites as a squashed commit v4-0000, however
> > this is not technically part of this series.
>
> The last update of this thread is from march 2024, with no replies and
> no reviews. Please note that this fails in the CI so I'd suggest a
> rebase for now, and I have marked the patch as waiting on author. If
> there is a lack of interest, well..

I can't say there is a lack of interest from the author per se :), but
not really seeing much in the way of community engagement makes me
think it's largely unwanted. I'd certainly be happy to rebase and
reengage, but if it's not wanted at the conceptual level it doesn't
seem worth the effort. It's hard to interpret lack of response as
"don't care, fine" vs "don't want" vs "haven't looked, -hackers is a
firehose".

Thanks,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-12-12 15:28:38 Re: pg_createsubscriber TAP test wrapping makes command options hard to read.
Previous Message vignesh C 2024-12-12 15:02:15 Re: Memory leak in pg_logical_slot_{get,peek}_changes