On Tue, May 05, 2020 at 11:59:27AM -0400, Tom Lane wrote:
! Well, the choice we face is preventing somebody's disk from spinning
! down, versus preventing somebody else from completely corrupting their
! database. From where I sit that's not a difficult choice, nor one
! that I feel a need to let users second-guess.
Then maybe You see a scenario where that feature would actually
prevent db corruption, while I have not yet found a realistic one.
Instead, what gave me headaches is that ZFS might take a single
tablespace (=pool) offline with the cluster continuing to run - and
I am not sure if the db is supposed to survive that (mine did, after I
had hit the power button in horror), nor is it easy to protect from
that.
Anyway, I can now switch that feature off per local patch, which is
the second-best solution.
! Oooh ... it looks like some of the encryption code paths have neglected
! to call gss_release_buffer. Will fix, thanks for the report!
Great! So I assume I don't need to send a bug report I had prepared
interim. Feel free to ask me for anything that might be still needed.
cheerio,
PMc
