>
> > Yeah, that's an excellent practive, but is why I'm less worried for
> > this feature. The docs at [1] caution about "not to remove earlier
> > backups if they might be needed when restoring later incremental
> > backups". Like Alvaro said, should we insist a bit more about the WAL
> >
Thanks Stephen, Bruce and Masahiko,
> > discussions so far and the point behind the design so that everyone
> > can understand why this feature is designed in that way. To do that,
> > it might be a good start to sort the wiki page since it has data
> > encryption part, KMS, and ToDo mixed.
>
>
Hello,
> > I don't think it makes sense to think about committing this to v14. I
> > believe it only makes sense if we have a TDE patch that is relatively
> > close to committable that can be used with it. I also don't think that
> > this patch is in good enough shape to commit yet in terms of
I met with Bruce and Stephen this afternoon to discuss the feedback
we received so far (prior to Robert's note which I haven't fully
digested yet)
on this patch.
Here is what we plan to do:
1) Bruce is going to gather all the details from the Wiki and build a
README for the TDE Key Management
> > I have to admit I was kind of baffled that the wiki page wasn't
> > sufficient, because it is one of the longest Postgres feature
> > explanations I have seen, but I now think the missing part is tying
> > the wiki contents to the code implementation. If that is it, please
> > confirm. If it
> > > I think that's not at all acceptable. I don't mind hashing out details
> > > on calls / off-list, but the design needs to be public, documented, and
> > > reviewable. And if it's something the community can't understand, then
> > > it can't get in. We're going to have to maintain this going
On Thu, Apr 5, 2018 at 10:54 PM, Michael Paquier wrote:
> On Thu, Apr 05, 2018 at 04:02:20PM -0400, Bruce Momjian wrote:
>> Simon, you have three committers in this thread suggesting this patch be
>> reverted. Are you just going to barrel ahead with the fixes without
>>