Peter Eisentraut writes:
> On 2020-06-07 17:00, Tom Lane wrote:
>> Relevant to the current discussion: this creates a possible positive
>> reason for setting dynamic_shared_memory_type to "sysv", namely if it's
>> the best available way to get around RemoveIPC in a particular situation.
>> Should
On 2020-06-07 17:00, Tom Lane wrote:
Relevant to the current discussion: this creates a possible positive
reason for setting dynamic_shared_memory_type to "sysv", namely if it's
the best available way to get around RemoveIPC in a particular situation.
Should we document that?
It sounds like bot
Thomas Munro writes:
> On Mon, Jun 8, 2020 at 3:00 AM Tom Lane wrote:
>> ... Unfortunately it seems there's nothing
>> equivalent for POSIX shmem, so (2) is possible. See
> Ah, I see. Ok, I propose we update the example symptom to (2), and
> back-patch to 10. See attached.
+1, except s/attem
On Mon, Jun 8, 2020 at 3:00 AM Tom Lane wrote:
> Thomas Munro writes:
> > Not sure
> > what to put in its place... I guess the remaining symptoms would be
> > (1) the little "interlock" shmem segment is unregistered, which is
> > probably symptom-free (until you start a second postmaster in the s
Thomas Munro writes:
> One more thing I spotted, post commit: the example symptom of
> systemd's RemoveIPC feature trashing your cluster is an error from
> semctl(), but that can't happen anymore on a standard build.
Good point.
> Not sure
> what to put in its place... I guess the remaining symp
On Sun, Jun 7, 2020 at 3:42 PM Tom Lane wrote:
> Thomas Munro writes:
> > Yeah, I wasn't planning on changing anything in backbranches. It
> > sounds like we're OK with doing this for 13. Here's a version with a
> > few more changes:
>
> Looks pretty good to me. I attach a delta patch with a f
Thomas Munro writes:
> Yeah, I wasn't planning on changing anything in backbranches. It
> sounds like we're OK with doing this for 13. Here's a version with a
> few more changes:
Looks pretty good to me. I attach a delta patch with a few more
proposed adjustments. Notably, I made the wording
On Sun, Jun 7, 2020 at 4:39 AM Magnus Hagander wrote:>
> Oh they absolutely will. But most likely they will also use an older version
> of PostgreSQL because that's what their enterprise product supports. And
> we're not talking about removing the documentation from the old version (I'm
> assum
On Sat, Jun 6, 2020 at 6:35 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-06-06 17:14, Tom Lane wrote:
> >> Let's hope PG13 isn't that late -- the end of Extended Lifecycle
> Support is
> >> June 30, 2024 for RHEL 6. (It*enters* ELS around the time of pg 13).
> > ELS ba
On 2020-06-06 17:14, Tom Lane wrote:
Let's hope PG13 isn't that late -- the end of Extended Lifecycle Support is
June 30, 2024 for RHEL 6. (It*enters* ELS around the time of pg 13).
ELS basically means that they aren't going to take down the existing
website information about RHEL6 just yet.
Magnus Hagander writes:
> On Sat, Jun 6, 2020 at 4:41 PM Tom Lane wrote:
>> So I concur with dropping all this stuff, and while we're at it I'd vote
>> for getting rid of the oom_adj para. RHEL6 will be fully EOL around the
>> time PG13 comes out, so I don't believe anyone's making brand new ins
On Sat, Jun 6, 2020 at 4:41 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 2020-06-06 06:57, Thomas Munro wrote:
> >> We're carrying a bunch of obsolete and in one case insecure advice on
> >> kernel settings. Here's an attempt to clean some of that up.
>
> > These changes seem sensible t
Peter Eisentraut writes:
> On 2020-06-06 06:57, Thomas Munro wrote:
>> We're carrying a bunch of obsolete and in one case insecure advice on
>> kernel settings. Here's an attempt to clean some of that up.
> These changes seem sensible to me.
+1
>> HP-UX:
>> * Drop advice for v10. 11.x came ou
On 2020-06-06 06:57, Thomas Munro wrote:
We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings. Here's an attempt to clean some of that up.
These changes seem sensible to me.
HP-UX:
* Drop advice for v10. 11.x came out 23 years ago.
We still have a versio
Hi,
We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings. Here's an attempt to clean some of that up.
Linux:
* Drop reference to ancient systems that didn't have a sysctl command.
* Drop references to Linux before 2.6.
* I was tempted to remove the reference t
15 matches
Mail list logo
