Re: [GENERAL] clarification about standby promotion

hi, Tank you for the confirmation ! For the second part, I understand your explanation but I fail to see how checking what we have replayed against what we have received will confirm we have received everything (unless we are in sync replication). Have a good day ! Benoit.

Re: [GENERAL] Running out of memory the hard way ...

On Wed, 08 Feb 2017 10:44:24 -0500 Tom Lane wrote: > Albe Laurenz writes: > > Bill Moran wrote: > >> What I feel is the best way to mitigate the situation, is to have some > >> setting that limits the maximum RAM any backend can consume. > > > I'd

Re: [GENERAL] PostgreSQL on eMMC - Corrupt file system

Am 08.02.2017 um 07:25 schrieb Thomas Güttler: > Hi PostgreSQL experts, > > ... # Update After following the hints from [this answer][1], I could sync via owncloud for hours, and no file system error occurs. This is no big surprise since now only very few io-operations happen on the eMMC.

Re: [GENERAL] clarification about standby promotion

On Thu, Feb 9, 2017 at 4:53 AM, Benoit Lobréau wrote: > Hi, > > > I would like to clarify something about standby promotion. From the > sentence below. I understand that, during the promotion process, postgres > will replay all the available wals (from the archive or

[GENERAL] LDAP configuration

Hi All, I want to use pgsync method for LDAP configuration in current environment. So please help me and share the document or link for configuration. -Pawan

[GENERAL] clarification about standby promotion

Hi, I would like to clarify something about standby promotion. From the sentence below. I understand that, during the promotion process, postgres will replay all the available wals (from the archive or pg_xlog). https://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION

Re: [GENERAL] Running out of memory the hard way ...

On Wed, Feb 8, 2017 at 7:44 AM, Tom Lane wrote: > Albe Laurenz writes: > > Bill Moran wrote: > >> What I feel is the best way to mitigate the situation, is to have some > >> setting that limits the maximum RAM any backend can consume. > > > I'd

Re: [GENERAL] Running out of memory the hard way ...

Albe Laurenz writes: > Bill Moran wrote: >> What I feel is the best way to mitigate the situation, is to have some >> setting that limits the maximum RAM any backend can consume. > I'd delegate that problem to the operating system which, after all, > should know best of

Re: [GENERAL] Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

05.02.2017 22:05, I wrote: [...] And yes, running Process Explorer gave some new and unexpected input. During the period of this strange high load it claims 40% CPU is used by interrupts (normally 0.01%) and 3% used by backend postgres.exe (normally approx 0%). I'd guess this means some problem

Re: [GENERAL] Running out of memory the hard way ...

Bill Moran wrote: > If you run a transaction with lots of server side functions that use a > lot of memory, this can trigger the OOM killer in Linux, causing the > PosgreSQL backend to receive a SIGKILL and all the associated bad > stuff. > > Tuning the OOM killer is not sufficient. No setting

[GENERAL] Running out of memory the hard way ...

If you run a transaction with lots of server side functions that use a lot of memory, this can trigger the OOM killer in Linux, causing the PosgreSQL backend to receive a SIGKILL and all the associated bad stuff. Tuning the OOM killer is not sufficient. No setting I've found for the OOM killer