From: | Peter <pmc(at)citylink(dot)dinoex(dot)sub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: 12.2: Howto check memory-leak in worker? |
Date: | 2020-05-05 17:54:37 |
Message-ID: | 20200505175437.GA1980@gate.oper.dinoex.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Apitz | 2020-05-05 18:12:00 | Re: PostgreSQL client hangs sometimes on 'EXEC SQL PREPARE sid_sisisinst FROM :select_anw;' |
Previous Message | Wolff, Ken L | 2020-05-05 17:45:34 | Re: Lock Postgres account after X number of failed logins? |